Merging NT 4.0 Domains

Downloads
23557.zip

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.

Sizing SAM
When consolidating multiple NT domains that include user accounts, you must think about the size of the domains' SAM database. Microsoft says the maximum size is 40MB, but in our experience, expanding the SAM past about 20MB can cause performance and replication problems.

Each user account in a domain consumes approximately 1KB of space, each computer account requires about 0.5KB, and each global group uses about 4KB. Use these rough figures to calculate the size of your combined-domain SAM, then find the actual size of the SAM in your current domains to check against your calculated number. The SAM resides in \winnt\system32\config\sam; keep in mind that you might not migrate all the accounts from each domain (e.g., unused computer accounts for workstations that you've retired).

A Head Start
Before you start migrating, you should prepare both the donor and recipient domains. In the same way that doctors look for compatibility between donor and recipient when performing an organ transplant, a migration is much smoother if the donor and recipient domains are similar. Some key areas to align are as follows.

Namespaces. Large organizations will almost certainly have name duplications across their domains. Duplications can happen in usernames, computer names, group names, and other types of names; you must sort them out before migration. Use the Net User, Net View, and Net Group commands to dump your namespaces to text files. Import the files into Microsoft Excel and use Excel's VLOOKUP function to search for repeated values. If you have separate WINS infrastructures, consolidate them before you migrate (but after you resolve all name duplications between the WINS servers).

Logon scripts. Combine the logon scripts from the domains you're merging into one logon script that you run in all the domains. This step lets you iron out any logon-script problems before you actually migrate users.

NT System Policy. Align the global group names that you use to apply NT system policy, and make sure the policy is the same in each domain.

Service accounts. Change NT services that don't run under the System account to operate using accounts from the recipient domain. A service on a server in domain X can run using an account in domain Y if a trust is in place between the two domains and the account in domain Y has the correct permissions. Don't forget the services that run on workstations (e.g., Microsoft Systems Management Server SMS— 1.2's Package Command Manager).

Security. Try to define one security model that will work for the consolidated domain. Use migration as an opportunity to clean up security across your enterprise; however, don't let having a single security model become a prerequisite for migration because doing so can necessitate massive work that bogs down your progress.

A Phased Approach
If you have a large number of servers and accounts to migrate, you'll need to split the work effort into several phases. Four broad work streams that aren't fully independent of one another but that are only loosely coupled are user account migrations, domain controller (DC) migrations, non-DC server migrations, and workstation migrations.

Typically, you can migrate servers in the background with less external time pressure than you can user accounts. Also, you can migrate DCs and non-DC servers in parallel. Obviously, though, you must migrate the DCs according to a schedule that works with the migration of the non-DC servers and the user account migration because DCs play a role in authenticating machine and user accounts. You can migrate workstations in parallel with all the other migrations. A sensible approach might be to migrate your servers overnight during the week and leave the heavy-duty migration of accounts to the weekend.

We give you some guidance for each of the four work streams in the sections that follow. One important point to remember is that the user population will perceive the user account migrations as the most disruptive element of the migration.

Before you begin any of the phases, document your migration process in its entirety and run through it in the lab multiple times, each time improving your documentation and your process. Restore backups of the actual servers you're going to migrate into your lab environment, which you should set up to resemble your live environment as closely as possible. If you don't have a lab environment, build one. Rehearse to the point of actually walking into the live server rooms; many projects have come apart because the key to a crucial rack isn't available at the right time. Preparation time will reward you tenfold by producing fewer unpleasant surprises during the actual migration.

In addition to practicing for migration, you need to prepare users for it. As we said at the beginning of this article, merging domains disrupts users without providing much visible benefit. Thus, you need to explain the reasons behind the change—sell the project. Use any communication channels that you have at your disposal, and we don't just mean global email messages. Write an article for your corporate magazine. If the project is large enough, give it a brand, a name, an intranet site, or even a logo. Users will be much more accommodating if they know what's going on.

User Account Migrations
If you have a large number of user accounts to migrate from one domain to another, you probably won't be able to migrate them all in one session. The processing rate of the tool that you use to migrate accounts and the length of your downtime slot will determine the number of accounts you can migrate in one pass. If you can't migrate all the accounts at once, you might decide to migrate accounts based on the server on which their personal files are stored rather than on their workgroup. Such a plan will mean that for the duration of the migration, people from the same work team might be in different domains. This situation shouldn't be a problem from a shared-resource perspective if you're using a migration tool that can repermission the objects in the donor domain, but it's an absolute headache for administrators. Therefore, keeping the migration period as short as possible is a good idea.

The Right Tool for the Job
Anyone performing a migration of any real size should consider obtaining one of the good third-party tools on the market. When considering tools, create another evaluation matrix that lets you specify your migration's requirements and evaluate how the products meet the requirements. Some important features are

• The ability to examine and modify every embedded SID reference (including NTFS and registry references) for as many applications as possible (e.g., Microsoft Exchange Server, Microsoft SQL Server). We refer to this feature as "re-ACLing."
• The ability to maintain existing SID references until the migration is complete. The tool shouldn't delete the original SIDs right away; rather, it should add the new-account SID with the same permissions wherever it finds the original SID. This approach lets you back out of a migration stage that fails without having to restore.
• The ability to migrate account passwords from one domain to another.
• The ability to examine the SIDs of thousands or millions of objects on your LAN or WAN in a short time. Thus, an agent-based tool is a must.
• The ability to translate roaming user profiles and locally cached profiles for use by the migrated accounts. Again, because this task is a demanding one, it should be agent-based.

Some of the tools you might want to consider are from Aelita Software, BindView, NetIQ, and Quest Software (formerly FastLane Technologies). See Ed Roth, "NT-to-Win2K Migration Tools," September 2000, InstantDoc ID 9659, for reviews of these vendors' tools.

Vendors will sometimes rent you migration tools on a month-by-month basis or allow free temporary use of the tools if you engage consultants from a partner company. If you don't think you'll need the tool's facilities after your migration, you might look into these options.

Pay Attention to Your Users' Profiles
In our experience, the most disruptive aspect of account migration for users is trouble with their NT profiles. Migration tools typically copy a user's existing roaming profile to a folder with a different name, then perform a re-ACLing pass against each file, folder, and registry entry in the new copy. The tools then configure the newly created account for the user to use the new profile. This method is a good one because it leaves the original account with access to the original, untranslated profile, but the new profiles have the following disadvantages.

The profiles consume a lot of server storage. This migration approach consumes an amount of space on each profile-holding server equal to the amount already dedicated to storing roaming profiles. You must ensure that each affected server has enough free space before the migration commences.

Profile translation takes a long time. Translating roaming profiles can consume a significant proportion of the time a tool takes to perform a migration. Measure profile-translation time beforehand and take into account that some live migrations will occur across low-bandwidth WAN links that might further slow the process. Profile translation might be the determining factor in how many accounts you can migrate per session.

Profiles might become corrupted when users download them. When users log on with their new accounts, their locally cached profiles will no longer be appropriate (or accessible) for them. Each user will need to download a copy of his or her newly translated profile from the server. The download will take time and bandwidth, and in some cases, the new profile will become corrupted. Some users with large profiles won't have enough disk capacity on their workstation to hold their new profiles; the largest profile we've come across was in excess of 1.5GB. Have a tried and tested procedure ready to help your support staff deal with these problems.

Profiles must be current when you translate them. The migration tools translate the roaming copy of a user's profile, so you should ensure that roaming profiles are up-to-date before migration. Updating remote users' profiles is especially important because these users typically use cached profiles to log on.

Tricks of the Trade
Here are some tips that can make your life easier during a migration. We also include some scripts that might help automate parts of your migration process.

Decrease the amount of profile space required during migration. If you have a good backup of the user roaming profiles that you need to migrate, you can extract the bulky parts of the profiles before translation and reinsert them afterward to save migration time and disk space. Listing 1 and Listing 2 show sample DOS code that performs the extraction. You run the script in Listing 1 from a workstation just before migration. The script submits one near-future task for each user in a text-file list to the NT Task Scheduler on the server that holds the user's profile. This automated task copies some common file types from the user's profile to a temporary location. The code in Listing 2 specifies the file types to copy. After migration, you need to use a reverse procedure to copy the users' displaced files to the new profiles; the files would then inherit permissions from the newly translated profiles' top-level folder.

Disable user accounts during migration. You can reverse most user-account migrations that you perform with third-party migration tools simply by reenabling the user accounts in the source domain. Disabling user accounts on the source domain before migration (and reenabling them only if you need to back out of a migration) is a good idea. Disabling user accounts on the target domain until you've completed the migration is an even better idea. If the accounts are disabled, overzealous users can't try to log on before you've completed your crucial work.

Add a new Start menu item for migrated users. You might want to add a program to each migrated user's roaming profile Start folder—maybe a self-deleting batch file that performs some post-migration cleanup task or a dialog box with post-migration instructions for the user. The script in Listing 3 copies a new Start item into the roaming profiles of users listed in a text file. We haven't provided a Start item here; an example might be a script that prompts the user to update his or her contact information in the corporate telephone directory or a script that sends an email message that notifies the project Help desk that the user has just made his or her first post-migration logon.

Preserve your SAMs during migration. In case something goes horribly wrong, preserve each domain's SAM database throughout the migration process. We recommend that you take one of a domain's BDCs offline before you use your migration tool on that domain, and don't bring the BDC back online until a couple of days after migration. In case of disaster, you can promote the offline BDC to a PDC and use it to restore the domain to its predisaster state.

Send an email message to each user slated for migration. If you have a text file that contains a list of users to be migrated, you can use one of the command-line email programs available as freeware to send your users advance warnings or post-migration instructions. You might have to manipulate the user-list text file to associate the NT usernames with the correct email addresses first (again, Excel's VLOOKUP function might come in handy).

DC Migrations
Migrating a DC is more of a rebuild than a migration. For security reasons, you can't move DCs from one domain to another the same way that you can move a member server or workstation. (People might tell you otherwise, but moving a DC requires some messy registry work that we don't recommend and that Microsoft certainly doesn't support.) Keep in mind that you must leave the source domain's PDC running until you're ready to retire the domain, so you might need to move the PDC function to a different or new server.

Before you perform the rebuild, lift from the server the important data and parameters that you need. Afterward, you can replace what you removed. Some items that you might want to remove and replace are

• user data and profiles
• print queues
• applications and Microsoft BackOffice products (e.g., SMS sites)
• networking settings (e.g., IP addresses)
• DHCP and WINS details (the Microsoft articles "How to Move a DHCP Database to Another Windows Server" at http://support.microsoft.com/support/default.aspx?scid=kb;en-us;q130642, "Recovering a WINS Database from Other Backup Sources" at http://support.microsoft.com/default.aspx;scid=kb;en-us;q235609, and "Restore of WINS Database to a Different Server Fails" at http://support.microsoft.com/default.aspx?scid=kb;en-us;q170849 detail the procedures for saving and then restoring DHCP and WINS databases)

Member Server Migrations
You can freely move member servers between NT domains, so you don't need to rebuild them. Migrating a member server that's holding only user data is simple. You back up the server, change the domain in the Control Panel Network applet, and reboot. Perhaps the main thing to remember is that the server must be able to see the PDC in both the old and new domains.

You must be a little more careful with servers that run BackOffice applications such as Exchange or SQL Server because of the embedded SIDs in application-based ACLs and the operation of service accounts. You must verify that user accounts in domain X that use a service on a domain X server can still use the service if you move the accounts to domain Y before the server moves to domain Y. Likewise, you should verify that the accounts can use the service if you move the server first.

You might want to consider consolidating Exchange organizations at the same time you migrate domains. For details about how to migrate an Exchange organization, see Tony Redmond, "Planning an Exchange 2000 Migration Strategy," http://www.exchangeadmin.com, InstantDoc ID 8860.

Workstation Migrations
If your migration tool has a mechanism for migrating workstations, it might work if your workstations are on 24 * 7, but it won't work well for other environments. Workstation-migration mechanisms are particularly ineffective at migrating remote workstations, which probably won't be suitably connected at the time you want to migrate them.

To migrate a workstation, you must first delete its account in the old domain and create an account in the new domain. Then, you must prompt the workstation to join the new domain. You should also add the Domain Admins global group from the new domain to the local Administrators group on the workstation. Your particular workstation configuration might demand other changes as well (e.g., reconfiguring the SMS Package Command Manager service).

We suggest developing a mechanism that migrates workstations gradually and at a time when you know that they'll be available. You can write an addition to an NT logon script that makes use of standard Microsoft Windows NT Server 4.0 Resource Kit utilities such as Netdom, Usrtogrp, and Nltest to perform the migration. For more information about the Netdom command, see Mark Minasi, This Old Resource Kit, "Netdom's Member Option," May 1999, InstantDoc ID 5216, and "Netdom 2000," November 1999, InstantDoc ID 7311. Each client OS requires slightly different code, but you can apply a gradual approach to the task of migrating most workstation types.

The SIDs Are All Right
All the objects on servers that you've moved to the new domain still have ACL entries against them for the original user account SIDs that had permissions to those objects. A final pass of the migration tool will remove these references.

After you've migrated all the user accounts, (almost) all the servers, and all the workstations out of a domain, you should be left with only the PDC. Turn off the PDC for a trial period of a day to determine whether any dependencies on the now-empty domain still exist. When you can leave the PDC off for a period of a few weeks without any ill effects, you can consider the domain "dead." A ceremonial burial beneath the raised floor of the server room might not be inappropriate if the migration has gone well.

Infrastructure integration work can be extremely rewarding, but you'll probably need to get your accolades from your teammates. If you've done your job well, users won't notice any difference other than that they now log on to a different domain and some had to bring their laptops in on a specified day for some updates. Do the job wrong, and you could be cleaning up for months. As we've tried to convey, the secret to success is solid preparation and incredible attention to detail. Miss nothing, challenge all your assumptions, and make sure you have an account with the local pizza delivery company to get you through those long migration evenings and weekends.