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.
Prev. page
1
[2]
3
4
5
next page 
