Merging NT 4.0 Domains

If you must recreate 10,000 user accounts, modify 8000 workstations at 30 sites, and rebuild 200 servers without giving users much immediate benefit, the best you can hope for is that they barely notice you've done anything. Welcome to the thankless world of infrastructure integration.

Not many organizations have a single-domain environment from which they can easily migrate to a nice, clean single-forest/single-domain Windows 2000 implementation. Corporate acquisitions, bandwidth constraints, administrative requirements, and politics often leave a mishmash of domains and trust relationships. For many, therefore, the first stage in moving to Win2K is a subproject to merge the existing Windows NT 4.0 domains and clean up any untidiness that has accumulated along the way. We've been through this cycle of migration and can navigate you around some of the pitfalls of domain integration, giving you some useful techniques for reducing the disruption to your users.

The principles you must apply to see through a successful NT 4.0 domain merge are practically the same as those for an NT 4.0­to-Win2K migration. So don the cloak of the invisible man and start merging.

The Problem with SIDs
In NT 4.0, you can't just move a user account from one domain to another. Each user account, global group, local group, and workstation in the domain has a unique number, called a SID, that's linked to the domain. A SID comprises a common, domainwide prefix followed by a unique suffix for the account, called a Relative Identifier (RID). Because accounts are associated with a particular domain, you can't move them between domains; migrating a domain means that you must recreate from scratch in the target domain each of the source domain's user accounts, group accounts, and computer accounts. These new accounts must have exactly the same properties as the original accounts.

Win2K and NT 4.0 security use an account's SID rather than its name. You'll find references to SIDs in ACL entries. The most visible type of ACL is the list of permissions applied to a file or folder, but SIDs also appear elsewhere. The sidebar "Do You Know Where Your SIDs Are?" provides a list of SID-reference locations.

Unfortunately, the widespread use of SIDs means that each of your NT domains likely has hundreds of thousands or even millions of SID references. And of course, you need to add the same permissions for each newly created account (and new SID) in the merged domain to each ACL on which the old account's SID appeared. Obviously, you'll need a tool for dealing with SID references in your domain during migration. We discuss migration tools later in this article.

Choosing a Domain
To reduce the number of your domains, you can create a new domain and fold your existing domains into it, or you can pick one of your existing domains and fold the other existing domains into it. Your first inclination might be to start fresh with a clean domain. However, the above discussion of SIDs alone should be enough to convince you that starting with a new domain is a far less attractive option. Migrating two domains of equal size into a new domain means moving twice as many accounts as you would if you folded one domain into the other. Doubling your work isn't a good idea unless both domains are so untidy that a clean break justifies the extra effort. If you fold one domain into the other, you'll need to first clean up the domain that will remain, but using an existing domain is typically the easier option in the end.

The next question is, which domain should be the donor and which the recipient? You might be surprised to discover that the questions of which domain will become the "master," what its name will be, and where the PDC will sit can quickly become more political than technical.

The best way to try to take the politics out of the situation is to introduce a more objective assessment technique such as an evaluation matrix. Identify a set of selection criteria and weight each criterion based on its importance. After you create the matrix, evaluate each domain against the criteria and assess the results. This process is still partly subjective and therefore open to political debate, but it should simplify things. Table 1 shows a sample matrix, with the assessment criteria split into effort, disruption, and suitability indicators.

Your conclusions will depend on how you weight the indicators. For example, if your goal is to migrate with the minimum amount of effort, you'll weight the effort indicators more heavily than the disruption and suitability indicators, and you'll choose the ENGLAND domain as the receiving domain. If you're willing to expend extra effort to achieve higher quality results, you'll give suitability greater weight, and you'll select the CANADA domain as your receiving domain.

   Previous  [1]  2  3  4  5  Next