March 24, 2011, 9:05 a.m.
posted by sensei
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 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:
Preparing for a Domain Upgrade
There are three important steps in preparing for a domain upgrade:
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 and fail miserably. 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.
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.root.com, add a completely different noncontiguous tree called mycorp.com to the same forest, and subsequently remove testdom.root.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.
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 want 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, 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.
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.
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.
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 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.
Solution 3: Migration to separate domain trees in a forest
Finally, you could make each domain a separate tree. Although 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.
Migration to a new forest root domain
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
Migration with one domain as tree root
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.[*] 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.
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.
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 the 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:
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.
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:
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 want 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 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
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 want 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 Chapters 7 and 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 they can be deleted.
When consolidating domains, at some point you will need 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, which requires you to have upgraded or decommissioned all of your Windows NT BDCs. This allows a seamless transfer of the user object, including the password.
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,DC=mycorp,DC=com /ddn OU=Sales-Managers,DC=mycorp,DC=com /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 as follows:
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.