Most of these offerings have evolved from products that let network managers delegate the administration of some aspects of a domain, such as changing the members of a group or users' passwords, to subadministrators under Windows NT. In fact, several software companies have found the concept so attractive they've snapped up domain-administration companies. In the past few months, BindView has bought Entevo Corp., NetIQ has acquired Mission Critical Software and Quest Software has merged with FastLane Technologies.

Our Editor's Choice award goes to NetIQ's DMA. We especially like its ability to model a migration to a database for examination and reflection and then apply the model, or to migrate directly from an NT domain to an Active Directory domain. Coming in second was BindView's suite, which missed first place mainly because of its slow rate of converting domains. Aelita's and FastLane's products finished just a hair from each other. Although each of the contenders was a powerful tool for reconfiguring Windows NT domains to Active Directory, none of the products provided everything that we were looking for in a migrating tool. This market is still new, and the products are correspondingly immature.

Microsoft does offer the Active Directory Migration Tool (ADMT), but it's best suited to small networks only with exclusively native-mode Active Directory domains. It doesn't perform SIDhistory (security ID history) cleanup, an important step.

All the tested products provide more than the basic core functionality needed to migrate from Windows NT to Active Directory. They all let us easily move users and groups from source Windows NT domains to Active Directory domains and OUs (organizational units); remove, disable or set expiration dates on the source accounts; move computers to the new domains; and update the ACLs (access control lists) on resources to give the new accounts access to those resources.

Be aware that all four of these products are licensed on a per-migrated-user basis. For example, if you combine users' multiple accounts when you merge four Windows NT domains, even though your user accounts may decrease during the conversion (say, from 4,000 to 2,500), you are still required to purchase a license for the amount of accounts you had before the conversion. We found this to be a fair model for licensing, because the amount you pay is based on how much you use.

Revising the Domain Model

Microsoft's previous domain model was clunky at best and often truly unwieldy. For example, one of our consulting clients had branch offices scattered throughout the country, each of which housed a salesman from every product division, a sales manager and a secretary. Using Windows NT domains, we could have created either a domain for each division as other considerations (including office politics) dictated or a domain for each sales office.

Unfortunately, neither was a good solution. Using divisional domains would have required a BDC (backup domain controller) for each of the five divisional domains in each sales office; otherwise, some users might not have been able to log in if the WAN link went down. Five BDCs also would have meant a lot of domain update traffic. Using office domains required only a PDC (primary domain controller) and a BDC at each office, but made administration a nightmare as trust relationships between 50 domains had to be created and monitored and 50 backup domain controllers set up at headquarters.

In Active Directory, we could create an OU for a division in a sales domain, letting divisional administrators manage their users, while a single domain controller with a global directory in each office serviced all the users as well.

While this sounds like a good idea, it's not without problems. The SIDhistory API works only with Active Directory native-mode domains that have exclusively Windows 2000 domain controllers. The additional SIDs make it substantially more difficult to analyze ACLs and ownerships for resources, especially for Apple Computer Macintosh volumes (which use ownership to manage access permissions) or if you've deleted the domains that originally held the users. When the original domains have been deleted, all you see when looking at the permissions to a resource is "account unknown" for users whose accounts have been migrated. Network bandwidth and performance could be hurt by the increased size of security tokens, which contain not only the SIDs of the user's new account and groups in the destination domain but also all the user IDs and groups that were associated with that user in all the source domains. Each user/group that has access to a resource such as a file has an entry in the ACL. A typical file on an NT server will have five to 10 objects in its list with SIDhistory. This could grow three to five times.

We, and fortunately the developers of these products, therefore look at SIDhistory as a stopgap measure that makes the transition easier. All four vendors support both updating SIDhistory when moving users and cleaning it up after the migration is complete. We recommend you use SIDhistory until you're ready to turn off the domain controllers for your old domains. At that point--OK, really just before--you should run a SIDhistory cleanup to re-ACL your resources to contain the new SIDs and delete the SIDhistory. Having to re-ACL, which deletes references to old user IDs and group SIDs and adds new IDs to the ACL for resource, is the most onerous part of migrating to Active Directory. If problems arise during migration, you can undo it to return to the original state. The ACL process is transparent to clients.

One early decision you should make in planning your migration is when to start domain restructuring. You can view the migration as an opportunity to restructure and do it while switching to Windows 2000 and Active Directory or take a more conservative approach and at least start restructuring before changing operating systems.

If you choose to restructure and then change to Active Directory, BindView's Bv-Admin is a good choice, as you can use its delegated administration tools to get your administrators accustomed to some Active Directory concepts. The other products offer similar features, but Bv-Admin is more Active Directory-like in managing Windows 2000. On the downside, BindView's solution operates so slowly that converting even a small domain (three to four servers with 100 GB of data) will take longer than a weekend. If you don't want to change your NT domain structure before installing Active Directory, FastLane's DM/Manager is a good choice for many small migrations.