Migrating NT Workstations to a New Domain

In this era of rapidly changing technologies and large-scale acquisitions, many companies are modifying their network server structures. (For information about renaming a domain on Windows NT servers, see Joe Rudich, "Same Domain, New Name," February 1999, and Sean Daily, "How to Rename Your NT Domain," February 1999.) These network modifications require some companies to migrate many NT workstations from one domain to another, a migration that is usually complicated and time-consuming for administrators. Moving an NT workstation typically requires IS personnel to manually alter the client at the desktop level, for two reasons.

First, the directory structure and Registry of every NT machine store a user profile for each user account that logs on to the system. The profile saves all the user-specific desktop, mail client, and Internet Explorer (IE) settings. (For information about user profiles, see Drew Heywood, "Windows NT User Profiles," September 1997, and Gregg Branham and Jon McDonald, "Profiles, Policies, and Logon Scripts," December 1997.) When a user logs on, NT uses the user account's unique security ID (SID) to find that user's profile in the Registry. If the user doesn't have a profile on that machine, NT copies the local Default User profile directory to create a new profile for the user account, unless the account specifies a roaming profile. If you move a user account to a new domain, the new domain assigns the account a new SID, so the first time the user logs on after the move, the workstation creates a new profile for the new SID. As a result, the user loses the settings the profile contained.

When you're moving NT workstations between domains, you want to let users log on to the new domain with their old profiles, but NT Workstation won't let you write a simple logon script to copy a user's existing profile into the new domain's profile directory. A user's profile contains an ntuser.dat file that stores the user's Registry hive, which contains all the system information about the profile. NT keeps ntuser.dat open whenever the user is logged on, so you can't write to or copy from the file while the user is logged on.

You can overcome this limitation by setting up roaming profiles in the old domain and the new domain and modifying NTFS permissions to let the old and new user accounts access both profiles during the migration. However, this approach requires a lot of disk space on your server. In addition, roaming profiles cause problems for remote users because NT backs up and restores remote users' roaming profiles each time they dial in to the network (a painful prospect over a slow link).

The second reason you usually must access users' desktops to migrate workstations is that you must re-create in the new domain each computer's account from the original domain. This account re-creation requires a higher level of administrative rights than most users have. Therefore, you can't migrate workstation accounts through logon scripts that run under workstation users' accounts. Migrating workstations requires administrators to either create machine accounts from the server side by writing a script that includes each machine's name or give target users the right to add workstations to the domain. Neither option is desirable for most administrators.

However, you can use this article's three logon scripts and a couple of utilities from Microsoft Windows NT Server 4.0 Resource Kit to eliminate most of the migration's complexity. Through a process that modifies the target machines' Registries, you can remove each workstation from its old domain and add it to its new domain without intervening at the desktop level. The migration is invisible to your end users, except for the brief period during which the logon scripts run. The process preserves all users' desktop settings and configurations, Microsoft Exchange Server client settings, Internet browser settings, and machine names.

Logon Script Fix
You can solve the problem of migrating users' profiles by writing a logon script that renames a user's existing profile Default User so that the new domain account adopts the profile from the user's old domain account when the script runs. This method retains user profiles with few complications. The catch is that because NT locks down the profile directory and ntuser.dat during logon, you must use an account other than the user's old domain or new domain account to rename the directory.

Introducing a third user account also solves the computer account problem. An account with the necessary permissions can add a computer account to the new domain from either the server or the client. When you're dealing with many client computers, adding the computer account is easier from the client side than from the server side. By adding the computer account from the client side, IS personnel can clearly identify at any time which machines have migrated into the new domain and can clean up the old domain's computer account list to remove these machines.

To migrate user profiles and computer accounts with logon scripts, you must use an account that is a member of every workstation's local Administrators group and that has the Add Workstations to the Domain right in the new domain. You need to create an account for the migration; in this article, we call the migration account Migrate, the new domain NEWDOMAIN, and the users' original domain OLDDOMAIN. You can use logon scripts to grant Migrate local administrative rights on each workstation you're migrating; however, keep in mind that this method requires the user who runs the logon script on each system you migrate to be in the system's local Administrators group, because the user account must add Migrate to the local Administrators group and must make administrative Registry modifications.

The Migrate account can reside in either domain, but it requires a two-way trust relationship between the domains. To move the computer accounts, Migrate must access each workstation both before and after the domain move, but Migrate must remain in the same domain. If you don't want to create a two-way trust between the domains, you can use the logon scripts and Migrate account to move users' profiles but add the computer accounts to the new domain from the server side before the migration. However, we recommend creating the computer account on the client side during the migration to ensure that the new domain's computer accounts list is free from extraneous entries.

Our client migration's first logon script, first.bat, runs under the target user's OLDDOMAIN account and prepares the workstation for the migration. First.bat captures user information, makes the Migrate account a member of the local Administrators group, and modifies the Registry to let the Migrate account automatically log on. First.bat also configures the machine to remain connected via Remote Access Service (RAS) when a user logs on through a dial-up connection, and the script locks down the workstation so that the user can't interfere with the Migrate account's logon.

Our second script, second.bat, performs the core of the migration. This script runs under the Migrate account; it uses the user information that first.bat captures to migrate the user's profile, so that the workstation adopts the user's OLDDOMAIN profile when the user first logs on to NEWDOMAIN. The script also moves the workstation account from the old domain to the new domain. Finally, the script disables the automatic logon feature and returns control of the machine to the user.

Our third script, third.bat, runs under the target user's NEWDOMAIN account and prepares the machine to return to its usual business. The script removes OLDDOMAIN's accounts from the machine's local groups and changes Registry values that the other two scripts alter, back to their premigration settings.

The scripts are batch files that use several resource kit utilities; for more information about the utilities, see Table 1. The scripts use three standard environment variables: %OS%, %USERNAME%, and %USERPROFILE%. They also use the syntax %0\..\, which uses the location from which the script executes to locate other files. (For more information about %0\..\, see the Microsoft article "Use of the %0\..\ Syntax in the Smsls.bat File" at http://support.microsoft.com/support/kb/articles/q121/3/87.asp.)

Before you run the scripts, you must create an account in the new domain for every user who will migrate; you can use the resource kit's addusers.exe utility to create these accounts. You must provide users their new accounts' passwords before the migration. And you must designate first.bat as the logon script for each user's old domain account, second.bat as the logon script for the Migrate account, and third.bat as the logon script for each user's new domain account.

   Previous  [1]  2  Next