15.1 The Principles of Upgrading Windows NT Domains

There are many reasons that you will want to upgrade your Windows NT domains to Active Directory, not least of which is to make use of Active Directory and other features. It's possible to have significantly fewer domains in Active Directory because each domain can now store millions of objects. While fewer domains means less administration, the added benefit of using organizational units to segregate objects makes the Active Directory represent a business more accurately, both geographically and organizationally, and is a significant step forward. Couple this with the ability to set ACLs on objects and their properties in Active Directory, and you get much more fine-grained control for administrative delegation than before. You also can start phasing out old services, such as Windows Internet Naming Service (WINS) and extraneous Windows NT Backup Domain Controller (BDC) servers, since the clients now make more efficient use of DCs via TCP/IP and DNS. With all these improvements, the goals of upgrading a domain are easy to state:

Reduce the number of domains in use since it is easier to administer fewer domains.
Gain an extensible schema that allows much more corporate information to be stored than was previously possible.
Create a hierarchical namespace that as closely as possible mirrors the organizational structure of the business.
Gain much more fine-grained control over delegation of administration without needing to resort to the use of multiple domains.
Reduce network bandwidth use by DCs through both multimaster replication and a significantly more efficient set of replication algorithms.
Reduce the number of PDCs/BDCs to a smaller number of DCs through a more efficient use of DCs by clients.
Eliminate the need for reliance on WINS servers and move to the Internet-standard DNS for name resolution.

To get the maximum benefit from the new technologies, you really need to upgrade both clients and servers.

15.1.1 Preparing for a Domain Upgrade

There are three important steps in preparing for a domain upgrade:

Test the upgrade on an isolated network segment set aside for testing.
Do a full backup of the SAM and all core data prior to the actual upgrade.
Set up a fallback position in case of problems.

We cannot stress strongly enough how enlightening doing initial testing on a separate network segment can be. It can show a wide variety of upgrade problems, show you areas that you never considered, and in cases in which you have considered everything, give you the confidence that your trial run did exactly what you expected. In the world of today's complex systems, some organizations still try to roll out operating system upgrades and patches without full testing; this is just plain daft. The first part of your plan should be for a test of your upgrade plans.

When you do the domain upgrade itself, it goes without saying that you should have full backups of the Windows NT SAM and the data on the servers. You would think this is obvious, but again we have seen a number of organizations attempt this without doing backups first.

The best fallback position is to have an ace up your sleeve, and in Windows NT upgrade terms, that means you need a copy of the SAM somewhere safe. While backup tapes are good for this, there are better solutions for rapid recovery of a domain. These recipes for success require keeping a PDC or a BDC of your domain safely somewhere. In this context, by safely we mean off the main network. Your first option is to take the PDC off the network. This effectively stores it safely in case anything serious goes wrong. Next, as your domain now has no PDC, you need to promote a BDC to be the PDC for the domain. Once that has been done successfully, and you've manipulated any other services that statically pointed at the old PDC, you can upgrade that new PDC with the knowledge that your old PDC is safe in case of problems. The second option is to make sure that an existing BDC is fully replicated, then take it offline and store it. Both solutions give you a fallback PDC in case of problems.

15.1.2 Forests and the Forest Root Domain

Remember that the first domain in a forest is a significant domain and cannot be deleted. That means you cannot create a test domain tree called testdom.mycorp.com, add a completely different noncontiguous tree called mycorp.com to the same forest, and subsequently remove testdom.mycorp.com. You have to make sure that the first domain that you ever upgrade is the major or root domain for the company. In Windows NT domain model terms, that means upgrading the master domains prior to the resource domains. The resource domains may end up being Organizational Units instead anyway now, unless political, cultural, or bandwidth reasons force you to want to keep them as domains.

15.1.3 Windows NT Domain Upgrades

Single Windows NT domains and complete trust domains can be upgraded with few problems. With a single domain, you have just one to convert, and with complete trust domains, every domain that you convert will still maintain a complete trust with all the others. However, when you upgrade master domains or multimaster domains, there are account and resource domains that need to be considered. No matter how many master domains you have, the upgrade of these domains has to be done in a certain manner to preserve the trust relationships and functionality of the organization as a whole. We'll now explain the three broad ways to upgrade your master domain structure.

Let's assume that you have one or more single-master or multimaster domains that you wish to convert. Your first task will be to create the forest root domain. This domain will act as your placeholder and allow you to join the rest of the domains to it. The forest root domain can be an entirely new domain that you set up, or you can make the first domain that you migrate the forest root domain.

Take a look at Figure 15-1, which shows a Windows NT multimaster domain. Each domain that holds resources trusts the domains that hold user accounts, allowing the users to log on to any of the resource domains and use the respective resources.

Figure 15-1. Windows NT multimaster domain prior to migration

There are three main ways to upgrade this domain. None of them is necessarily any better than the other, as each design would be based on choices that you made in your namespace design notes from Chapter 8.

15.1.3.1 Solution 1—Migration to a new forest root domain

First, the domains could all be joined as one tree under an entirely new root. Each master domain would represent a branch under the root with each resource domain joined to one of the masters. This is shown in Figure 15-2.

Figure 15-2. Migration to a new forest root domain

While it is conventional to think of the resource domains under the master domains, there is nothing to stop you from joining resource domains under resource domains if you like; it will make no difference for access to the resource domain's data.

15.1.3.2 Solution 2—Migration with one domain as the domain-tree root

The second option is to aim toward making one of the master domains the root of the new tree. All resource domains could then join to the root, one of the other master domains, or one of the resource domains. Figure 15-3 shows this in more detail. Two resource domains have been joined to one of the master domains, but the third resource domain can still go to one of three parents, as indicated by the dashed lines.

Figure 15-3. Migration with one domain as tree root

15.1.3.3 Solution 3—Migration to separate domain trees in a forest

Finally, you could make each domain a separate tree. While the first master domain that you migrate will be the forest root domain, the rest of the master domains will simply be tree roots in their own right.

15.1.4 A Solution-Independent Migration Process

Let's now consider the process for migrating these domains. We must migrate the master account domains first, since they are the ones that the resource domains depend on. To start the process, convert any one of the master account domains over to Active Directory by upgrading the PDC of that master domain. If any of the trust relationships have been broken between this domain and the other master and resource domains during migration, reestablish them. Once the PDC is upgraded, proceed to upgrade the other BDCs of that domain (or you can leave the domain running with Windows NT BDCs; it doesn't really matter to the rest of the migration).

The next step is to migrate the other master domains. You continue in the same manner as you did with the first domain until all master domains have been converted. Once each domain is converted, you need to reestablish only trust relationships with the existing Windows NT domains; the Active Directory domains in the forest will each have hierarchical and transitive trusts automatically anyway. So now you end up with a series of Active Directory master domains in a tree/forest and a series of Windows NT resource domains with manual trusts in place.

Once all the master domains are converted, you can start consolidating them (as discussed in the next section), or you can immediately convert the resource domains. Either way, once all domains are converted, you are likely to start a consolidation process to reduce the number of domains that you have in existence. Part of that consolidation will be to convert existing resource domains to Organizational Units. This is because resource domains by their very nature tend to fit in well as Organizational Units.^[1] For that to happen, these future Organizational Units will need to be children of one of the migrated master or resource domains. It doesn't matter which master or resource domain acts as the parent, since there are consolidation tools available that allow you to move entire branches of the tree between domains. The process is simple: you take each resource domain in turn and convert it to a child domain of one of the existing Active Directory master or resource domains. Once they are all converted, you can really begin consolidation.

^[1] Resource domains were created because of Windows NT's inability to allow delegation of authority within a domain. Now Organizational Units provide that functionality, so separate resource domains are no longer required. Thus, old resource domains can become Organizational Units under Windows 2000 and still maintain all their functionality.

15.1.5 Consolidating Domains After the Move

Upgrading your domains is not the end of the story. Many administrators implemented multiple Windows NT domains to cope with the size constraints inherent in Windows NT domains. With Active Directory, those constraints are lifted, and each domain in a forest can easily share resources with any other domain. This allows administrators to begin removing from the directory information that has become unnecessary in an Active Directory environment.

15.1.5.1 Windows 2003 Interim and Windows 2003 functional levels and groups

When your final Windows NT 4.0 BDC for a domain has been taken out of service or upgraded, you are ready to convert the domain to Windows 2003 functional level. After the conversion, you have some decisions to make about the groups you have in this domain. You can leave all groups as they are or start converting some or all groups to universal groups. With multiple domains in a single forest, you can consolidate groups from more than one domain together into one universal group. This allows you to combine resources and accounts from many domains into single groups.

There are two methods for bringing these groups online:

Setting up parallel groups
Moving existing groups

In a parallel group setup, the idea is that the administrator sets up groups that hold the same members as existing groups. In this way, users become members of both groups at the same time, and the old group and a user's membership can be removed in a calculated manner over time. The arguably easier solution is to move existing groups, but to do that you need to follow a series of steps. Take the following example, which leads you through what's involved.

Three global groups—part_time_staff in finance.mycorp.com, part_time_staff in mktg.mycorp.com, and part_time_staff in sales.mycorp. com—need merging into one universal group, to be called part_time_staff in mycorp.com. The following is the step-by-step procedure:

All part_time_staff global groups are converted to universal groups in their current domains.
To make the part_time_staff universal group names unique so that they can all exist in one domain, the group needs to be renamed with the domain element. That means finance\part_time_staff, mktg\part_time_staff, and sales\part_time_staff become finance\finance_part_time_staff, mktg\mktg_part_time_staff, and sales\sales_part_time_staff.
Make use of the Windows 2003 functional level ability to move groups, and move the three groups to the mycorp.com domain. This leaves you with mycorp\finance_part_time_staff, mycorp\mktg_part_time_staff, and mycorp\sales_ part_time_staff.
Create a new universal group called part_time_staff in the mycorp. com domain.
Make the mycorp\finance_part_time_staff, mycorp\mktg_part_time_ staff, and mycorp\sales_part_time_staff groups members of the new mycorp\part_time_staff universal group.

You can then remove the three old groups as soon as it is convenient. Remember that, while this is an easy series of steps, there may be an entire infrastructure of scripts, servers, and applications relying on these groups. If that is the case, you will need either to perform the steps completely, modifying the infrastructure to look at the new single universal group after Step 5, or modify the groups immediately after you complete Step 2 and then again after you complete Steps 3 to 5 in quick succession. We favor the former, since it requires that the work be done once, not twice.

You should not underestimate the amount of work in analyzing what parts of the infrastructure make use of each group, planning the changes to that infrastructure, and ultimately implementing the changes. The preceding example was for one set of groups. If you have a significant number of groups, this is no small undertaking, and managers should be made aware of this fact.

15.1.5.2 Computers

When it comes to considering computer accounts, things are relatively straightforward. Under Windows NT, a computer could exist in only one domain at a time, since that computer and domain required a trust relationship to be established to allow domain users to log on to the domain at that client. You could set up bidirectional trust relationships manually between domains, allowing a client in Domain A to authenticate Domain B users to Domain B, but this was not common. With Active Directory, all domains in a forest implicitly trust one another automatically. As long as the computer has a trust relationship with one domain, users from any other domain can log on to their domain via the client by default. The following is a rough list of items to consider:

Moving computer accounts between domains to gain better control over delegation
Joining computers to the domain
Creating computer groups
Defining system policies

In all of these, it is important to understand that the source domain does not have to be at the Windows 2003 functional level to move computers to a new domain. In addition, administrators can use the NETDOM utility in the Windows Support Tools to add and remove domain computer objects/accounts; join a client to a domain, move a client between domains; verify, reset, and manage the trust relationship between domains; and so on.

While you may have had computer accounts in a series of domains before, you now can move these accounts anywhere you wish in the forest to aid your delegation of control. Group Policy Object processing also has a significant impact on where your computer accounts should reside. However, you now can work out what sort of Organizational Unit hierarchy you would ideally wish for your computer accounts and attempt to bring this about. Moving computers between domains is as simple as the following NETDOM command.

Here we want to move a workstation or member server, called mycomputerorserver, from the domain sales.mycorp.com to the location LDAP://ou=computers,ou=finance,dc=mycorp,dc=com. We specifically want to use the myDC domain controller and the MYCORP\JOINTODOMAIN account to do the move. Connection to the client will be done with the SALES\Administrator account, which uses an asterisk (*) in the password field to indicate to prompt for the password. We could just as easily have used an account on the client itself. We also include a 60-second grace period before the client is automatically rebooted:

NETDOM MOVE mycomputerorserver /DOMAIN:mycorp.com /OU:Finance/Computers
  /UserD:jointodomain /PasswordD:thepassword
  /Server:myDC
  /UserO:SALES\Administrator /PasswordO:*
  /REBOOT:60

This is actually the long-winded version, split up onto multiple lines for visibility; here's the short form:

NETDOM MOVE /D:mycorp.com /OU:Finance/Computers /UD:jointodomain 
  /PD:thepassword /S:myDC /UO:SALES\Administrator /PO:* /REB:60

Note that moving a Windows NT computer doesn't delete the original account, and moving a Windows 2000 computer just disables it in the source domain.

You also need to consider who will be able to add workstations to the domain. You can set up an account with join-domain privileges only, i.e., an account with the ability to make and break trust relationships for clients. We've used this approach with a lot of success, and it means that an administrator-equivalent user is no longer required for joining clients to a domain. Let's take the previous example, but this time we wish to both create an account and join a new computer to the domain with that account. This is the code to do that using NETDOM:

NETDOM JOIN mycomputerorserver /D:mycorp.com /OU:Finance/Computers
/UD:jointodomain /PD:thepassword /S:myDC /UO:SALES\Administrator /PO:* /REB:60

In all these NETDOM examples, we're using a specially constructed account that only has privileges to add computer objects to this specific Organizational Unit. At Leicester we precreated all the computer accounts, and the jointodomain account was used only to establish trusts between existing accounts; it had no privilege to create accounts in any way.

You also need to be aware that workstation accounts under Windows NT could not go into groups. Under Active Directory, that has all changed, and you can now add computers to groups. So when moving computers between domains for whatever purposes, you now can use hierarchical Organizational Unit structures to delegate administrative/join-domain control, as well as using groups to facilitate Group Policy Object (GPO) upgrades from system policies.

System policies themselves are not upgradeable. However, as explained in Chapter 7 and Chapter 10, you can use system policies with Active Directory clients and bring GPOs online slowly. In other words, you can keep your system policies going and then incrementally introduce the same functionality into GPOs. Since each part of each system policy is included in the GPO, you can remove that functionality from the system policy while still maintaining the policies application. Ultimately, you will end up replacing all the functionality incrementally, and the system policies will have no more policies left so can be deleted.

15.1.5.3 Users

When consolidating domains, you'll need at some point to move users around to better represent the organization's structure, to gain better control over delegation of administration, or for group policy reasons. Whichever of these it is, there are useful tools to help you move users between domains.

To be able to transfer users between domains, you need to have gone to Windows 2000 functional level, and this will have ditched all your Windows NT BDCs. This allows a seamless transfer of the user object, including the password. A good method for transferring users and groups so that no problems occur is as follows:

The first stage is to transfer all the required domain global groups to the destination domain. This maintains the links to all users within the source domain, even though the groups themselves have moved.
Now the users themselves are transferred to the destination domain. The domain global group memberships are now updated with the fact that the users have now joined the same domain.
You then can consolidate the domain global groups or move the domain global groups back out to the original domain again. This latter option is similar to Step 1, where you move the groups and preserve the existing links during the move.
Clean up the user's Access Control Lists to resources on local computers and servers, since they will need to be modified after the change.

If you do it this way, you may have fewer problems with group memberships during the transition. As for moving users, while you can use the Active Directory Users and Computers MMC to move containers of objects from one domain to another, there are also two utilities—called MOVETREE and SIDWALK—in the Resource Kit that can come in very handy.

MOVETREE allows you to move containers from one part of a tree in one domain to a tree in a completely different domain. For example, suppose we wish to move the branch of the tree under an Organizational Unit called Managers from the sales.mycorp.com domain to the Organizational Unit called Sales-Managers on the mycorp.com domain. The command we would use to start the move is something like the following, preceded by a full check:

MOVETREE /start /s sales.mycorp.com /d mycorp.com
  /sdn OU=Managers,DC=sales /ddn OU=Sales-Managers
  /u SALES\Administrator /p thepassword

The SIDWALK utility is designed to support a three-stage approach to modifying ACLs. Each stage of changing ACLs can take a while to complete and verify, sometimes a day or more. It thus requires some amount of system resources and administrator time. The stages are:

Planning: The administrator needs to determine what users have been granted access to resources (file shares, print shares, NTFS files, registry keys, and local group membership) on a particular computer.
Account mapping: Based on who has access to what resources on the system, the administrator can chose to delete old, unused security identities or replace them with corresponding new identities, such as new security groups.
Converting ACLs: Using the information from the planning and mapping phases, the third stage is the conversion of security identities found anywhere on a system to corresponding new identities.

At the time of going to press, these utilities were not finalized, and still others were coming onto the scene.

Specifically, MOVETREE has been updated to make modifications to the SIDhistory attribute of security principals. A new set of "cloning" tools (e.g., ClonePrincipal) is to be made available to allow a user or group to be cloned from a Windows NT or Active Directory domain to a Windows 2000 functional level or higher domain without removing the source account.

15.1.5.4 Member servers and removing domains

After you've migrated, you may want to get rid of some old domains entirely, move member servers between domains, consolidate multiple servers together, or possibly even convert a member server to become a DC. Whatever you're considering, moving member servers and their data while maintaining group memberships and ACLs to resources can be done. Again, as with users and computers, taking the process in stages helps ensure that there is less chance of a problem.

If you're considering moving member servers between domains or removing domains in general, these are the steps that you need to consider:

Make sure that the source domain and the destination domain are at the Windows 2000 or higher functional level.
Move all groups from the source domain to the target domain to preserve memberships.
Move the member servers to the destination domain.
Demote the DCs to member servers, removing the domain in the process.
Clean up the Access Control Lists to resources on local computers and servers, since they will need to be modified after the change.

[ Team LiB ]