Migrating NT Workstations to a New Domain

Getting Ready
First.bat, which Listing 1, page 110, shows, prepares the client system for the migration. When the user logs on to the system, first.bat executes. First.bat verifies that the client system is running NT, not Windows 98 or Win95. If the system is running Win98 or Win95, the script logs the user off and ends; if the client is running NT, the script continues. (For a sample script you can use to migrate Win98 or Win95 machines to a new domain, see the online sidebar "Migrating Windows 98 and Win95 Clients"; go to http://www.winntmag.com, and type 4975 in the instaNT Doc box.)

The user's OLDDOMAIN profile stores the username and domain name of the account that authenticates all persistently mapped drives. At callout A, in Listing 1, first.bat changes the Registry entries for all the system's mapped drives to reflect the user's NEWDOMAIN account. Then, the script uses the NET LOCALGROUP command to add the Migrate account to the system's Administrators group.

Next, first.bat creates system environment variables that the Migrate account will use in second.bat to identify the user profile that needs to migrate and add the user to the local Administrators group. The script sets the new environment variables, MigrateUser and MigrateProfile, to the OLDDOMAIN account's username and profile path.

At callout B, in Listing 1, first.bat sets up automatic logon for the Migrate account so that second.bat won't require user intervention. Notice that the script provides the Migrate account's password. Because of this security risk, you need to set up the Migrate account with a very restricted, mandatory roaming profile and give the account no rights on either domain except for Add Workstations to the Domain. First.bat locks down the Migrate logon so that no shell (e.g., NT Explorer) is open during the migration period.

At callout C, first.bat sets the value of the KeepRasConnections entry in the HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Windows NT\CurrentVersion\ Winlogon Registry key to 1. A KeepRasConnections value of 1 lets dial-up nodes remain connected to the network after their RAS users log off. The KeepRasConnections value must be 1 for you to migrate remote clients via their dial-up connections. Logoff.exe ends first.bat.

Making the Move
After first.bat logs the user off, NT begins the Migrate account's autologon and runs second.bat, which Listing 2, page 112, shows. At callout A, in Listing 2, second.bat moves the profiles for the target user and Default User to temporary locations. The script moves the Default User profile to a temporary directory, and moves the MigrateProfile environment variable (which first.bat assigned to the user's OLDDOMAIN profile) to the Default User directory. Then, the script uses the NET LOCALGROUP command to add the user's NEWDOMAIN account and NEWDOMAIN's Domain Admins group to the system's local Administrators group.

Next, second.bat disables the Migrate account's autologon and places the user's NEWDOMAIN account and domain name in the appropriate fields of the NT logon window. The script also reinstates the Explorer shell.

At callout B, in Listing 2, second.bat uses the NETDOM command to move the computer's account to the new domain. (Be sure to use NETDOM 1.7 or later, or the utility might not work correctly. For information about NETDOM, see Mark Minasi, "NETDOM," page 185.) Finally, second.bat uses the logoff.exe command to move to the final script.

Cleaning Up
When second.bat completes, the logon window appears, displaying the user's NEWDOMAIN username and domain name. The user must enter the password for the NEWDOMAIN account at this point. After the user logs on, the script creates a new profile for the username from the temporary Default User profile and runs third.bat, which Listing 3 shows. Third.bat starts (at callout A in Listing 3) by verifying that the client is running NT.

At callout B, in Listing 3, third.bat deletes the temporary Default User profile and replaces it with the original Default User profile. Then, third.bat sets the KeepRasConnections key to 0 to tell RAS to disconnect when the user logs off. Finally, third.bat removes all the OLDDOMAIN users from the system's local Administrators group. When third.bat ends, the migration process is complete.

Customizing This Solution
Before you use these scripts to migrate NT workstations between domains, determine whether you need to customize the scripts. Think about whether you want to log the migration's events. You have a lot of flexibility in deciding which parts of the migration to log. We recommend that you track user and machine migration by storing a log file on the local machine or at a common share point on a server; you can do this logging by placing echoes at various points in the scripts.

You also need to consider whether you'll need to migrate workstations that more than one user logs on to. You'll want to migrate each system only once, so if more than one user uses a workstation, you must track whether each machine has moved to the new domain. You'll want to migrate every user's profile, but after the first user logs on, you won't want the NETDOM command to execute in the scripts. You can use environment variables, Registry settings, and log files to remotely track the status of migrating machines. (You'll find these variables helpful if a machine crashes or loses power during a migration.)

The custom MigrateUser and MigrateProfile environment variables can tell you the logon ID and profile path of the last user to execute first.bat. You can use the DefaultUserName, DefaultPassword, and AutoAdminLogon values in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon Registry key to track the status of a migration. You can check these Registry values to determine whether second.bat has disabled the Migrate account's automatic logon. This information will help you determine whether the Migrate account has logged on to the workstation. You can use the custom environment variable DOMAINMOVE to see whether NETDOM has executed, and you can confirm that NETDOM was successful by verifying that the CachePrimaryDomain value in the Winlogon Registry key equals the new domain's name. You can check and correct all these values remotely if you want to avoid desktop intervention. If you use these variables and Registry values and create log files during system migrations, you might need to leave your desk only to refresh your cup of coffee.

Another major consideration that might require you to customize your scripts is the amount of hard disk space available on the workstations you're migrating. The migration method we've described requires the machine to store two copies of each user's profile during the migration. The typical Default User profile is about 512KB; this size varies depending on how and where users store their personal data. For example, if users are running Microsoft Outlook 98, the OS stores the users' offline storage folder, personal storage folders (PSTs), and Personal Address Books (PABs) in their profile directory, which increases the profiles' size. We have seen user profiles reach several hundred megabytes, but profiles of this size are extremely rare. If disk space might be a problem on some of your systems, you can develop a custom utility in C, WISE, or a scripting language such as PerlScript or Visual Basic Script (VBScript) that compares the size of the user's profile directory with the available space on the local hard disk before starting the migration. You can use your custom utility with the freedisk.exe resource kit utility to verify that users' workstations have space and terminate the workstation migration from within the script in the rare situations in which disk space is a problem.

In addition, you must consider your file servers and any NTFS permissions you have in place before you run the migration scripts, because you will have to reassign NTFS permissions to the new user accounts. Finally, be sure to give all migrating users information about their new logon passwords and domain names before the move. You'll probably also benefit from telling users that the logon scripts will execute when they log on and explaining that the users who moved will appear under a new domain in Network Neighborhood.

This article explains viable solutions to the problems NT Workstation migrations pose and provides examples of how you can implement these solutions. You can use other scripting tools, including compiled code, KiXtart, and Windows Scripting Host (WSH), to achieve the same results. If you use our scripts, your users won't notice the migration (other than the brief period during which the logon scripts run), calls to your Help desk will be minimal, and your workstations will successfully enter the new domain.

End of Article

   Previous  1  [2]  Next