Flatten Your NT Domain Structure

Get the most out of your network by consolidating your domain structure

There are many reasons to consider reconfiguring and consolidating your Windows NT domain structure. For example, you might heed Microsoft's recommendation to flatten your domain structure to prepare for Windows 2000 (Win2K). Perhaps your political or physical environment has changed from your initial NT domain concept. Or maybe you're planning to implement a new enterprise administration tool, such as Enterprise Administrator (EA) from Mission Critical Software or DM/Administrator from FastLane Technologies.

No matter what your reason for consolidating your domains, you'll reap many benefits from your reconfigured domain structure. For example, you can reduce your network's total cost of ownership (TCO): Fewer trust relationships, fewer domain controllers, and the ability to implement centralized administration contribute to bottom-line savings. In addition, reconfiguring your network provides new capacity for network expansion, tool implementation, and future upgrades.

Although domain configuration is different for every organization, Microsoft recommends four basic domain-structure models: Single, Master, Multiple-Master, and Complete Trust. You need to decide which model best fits your environment by considering such factors as where your users are physically located, how you distribute your resources, and what your company's physical and political boundaries are. If you plan to upgrade to Win2K, Microsoft recommends flattening your domain structure into a single domain.

In this article, I focus on methods of reconfiguring your current domain, so I don't detail how to decide which domain will work best for your environment. For more information about choosing the ideal domain structure for your company, see "Domain Migration Resources," page 118.

Project Preparation and Planning
The first step in consolidating your domain structure is to prepare your strategy. One of the greatest obstacles you'll have to overcome is the resistance to change within your organization. Convincing users to sacrifice some of their control or take on more responsibility is a challenge. To expedite the process, you need to clarify the project's plans and goals to every user and update management with each development.

To establish your project's goals and parameters, you need to develop a schedule. Discuss this schedule with the individuals who are responsible for given segments. These users can help develop the project schedule and set up a target time frame for their part of the project and the complete consolidation.

At this point in your preparation, consider maintenance that you can perform in your server environment while you reconfigure your domain structure, such as decommissioning old server models, consolidating resources, and rebuilding nonessential domain controllers into member servers. This preparation phase is also a good time to research third-party migration utilities.

Tools of the Trade
The migration of a domain structure is a complex process, and creating user accounts for every user and updating ACLs on every server is a daunting task. Several top-notch utilities can help ensure the success of your project. However, few tools on the market address the entire process.

I began researching migration utilities by investigating tools in the Microsoft Windows NT Server 4.0 Resource Kit, such as Subinacl and Xcacls. I discovered that I could use these tools to create scripts to perform the migration, but I quickly realized that an approach consisting of destructive changes wasn't realistic. Although you can use these utilities to replace existing ACLs for a user or group, they aren't useful when you want the flexibility to implement a parallel domain structure and perform an orderly migration. I needed a tool that created parallel ACL implementations and performed all the server-end migration steps, such as creating user accounts and updating ACLs on servers throughout the enterprise. DM/Administrator, EA, and Computer Associates' Unicenter TNG can aid in your migration. I found FastLane Technologies' DM/Reconfigure (formerly Phoenix Domain Leveler) useful, but I urge you to evaluate several products to find one that best suits your company's needs.

In addition to off-the-shelf tools, I required several homegrown tools to address user and workstation migration concerns. I used resource kit tools to write scripts that created powerful utilities for workstation processing. Perl scripting, Netdom, Shutdown, and Scanreg are a few of the tools that made automatic workstation processing possible.

The Technical Side
When you consolidate your domain structure, you'll encounter several environments, such as DHCP and WINS servers, domain controllers, SQL Server machines, and NT and Windows 9x workstations. Each system requires a different reconfiguration strategy and has a unique set of migration concerns.

Servers
Moving servers to a new domain structure sounds difficult, but this step can be the easiest transition of the project. NT servers can validate accounts across trust relationships, so you can move a server to another domain without affecting users' access to the server. The key to a smooth server transition is to have the proper trust relationships in place before moving the server. For example, in Figure 1, Domain B trusts Domain A; thus, you can move resources from Domain A into Domain B without affecting users' access to those resources. In addition, Domain A and Domain B trust the Master Account Domain, so you can move servers with ACLs for new accounts between Domain A and Domain B without affecting users' existing permissions and ability to access resources.

Domain controllers pose a challenge because they share a security database. When you install NT Server on a machine, the installation creates a SAM file, which contains the local security context for the machine. If the NT server is a domain controller, NT doesn't create a SAM file; instead, NT copies the file from the PDC. This security file has a domain security context. After the security database is in place, you can't move the machine to another domain unless you reinstall NT. The best way to overcome this challenge is to reduce the number of services running on domain controllers by relocating the services onto member servers before the user migration. This solution lets you shut down or rebuild domain controllers without worrying about reinstalling the resources. However, be sure you leave enough domain controllers to perform authentication; otherwise, users might experience problems logging on or accessing resources.

DHCP, WINS, and DNS servers also create a migration concern, particularly if domain controllers are running these services. These services don't rely on domain-level security, so you can migrate them to a new domain by changing their domain membership on the Identification tab of Control Panel's Network applet. However, these services depend on their TCP/IP address. Moving any of these services to a server with a different IP address requires careful planning. WINS servers depend not only on their IP address but also on domain credentials. Be sure to configure the administrative structure on your WINS server at the beginning of the migration process, so you can manage your WINS server after you move it to the new domain.

The most complicated aspect of server migration is updating the share, file, and printer ACLs for the users who access the server. Although you can use resource kit utilities such as Subinacl to automate ACL processing, using a third-party migration utility, such as DM/Reconfigure, is easier, faster, and safer. Migration utilities create users' accounts in a new domain and update the access rights on each server to include the users' new accounts. However, to make global changes to a server's ACLs, you need to have Administrator permissions on the server. I wrote a script, which Listing 1 shows, that simultaneously updated a server's Local Administrators group and moved the server into the new domain structure. Then, when I was ready to use a third-party utility to update a server's ACLs, the Administrator permissions were already in place.

When you perform a migration, you must remember that a user account is more than a username. A user account contains a unique security ID (SID) that directly or through group membership gives a user rights to resources throughout your company. An administrator can use this SID to give a user rights to any server or workstation in any domain that shares a trust relationship with the domain that contains the user's account. Therefore, you need to look closely at every user's ACL, so you don't accidentally deny users access to resources throughout your enterprise that they previously had permission to access.

Win9x Workstations
Win9x workstations present the fewest challenges of this project. You can perform the bulk of Win9x clients' migration by importing a simple Registry file. Listing 2 shows the Registry patch I used to quickly change a Win95 client's domain membership, security provider, and authenticating domain. However, this process creates migration concerns that you need to address.

When you migrate your Win9x users, there will be a time when any given user has at least two accounts—the original account and the account in the new domain structure. After you create the account in the new domain, but before the user logs on to the new account, the passwords for the old and new account aren't the same. Microsoft based Win9x architecture on workgroups, so Win9x network resource connection requests contain only a username and password and no domain identification. When the NT server receives a Win9x connection request, NT must guess the domain in which the Win9x connection request originated. First, the NT server searches the domain that the server is a member of. If the NT server doesn't find the Win9x user, it continues to query domains until it finds a match. If the NT server searches the new domain structure, the user's password in the credential won't match the new domain's credential and the authentication will fail. To address this problem, I created accounts in the new domain structure that were disabled until I was ready to use them, and I automatically disabled the old account a week after the user migrated. I also set the User Must Change Password at Next Logon flag on the new account and instructed users to use their old account's password for their new account.

Win9x RAS clients present another migration difficulty. When users log on to a RAS server, Win9x caches the domain that users log on to, so users don't have to provide this information the next time they connect. After Win9x caches this information, the OS isn't eager to change these credentials. To work around this problem, you can instruct users to erase their username when connecting to the RAS server, so that the RAS server prompts users for logon credentials, including domain information. Alternatively, you can parse the RAS section of clients' Registries and replace old domain information with the new domain name. I opted for the second option and used regedit and Perl to parse the RAS section of users' Registries. I used regedit to export the Registry key that contains the RAS cached credentials (i.e., HKEY_CURRENT_USERRemoteAccess Profile). Next, I used a Perl script to parse the file and replace every reference to the old domain with the new domain, as Listing 3, page 122, shows. Finally, I imported the new setting.

Another Win9x migration problem deals with the domain in which the RAS server resides. If the RAS server remains in the old domain structure until all the users migrate, you'll have problems disabling the old user accounts as users migrate. However, you'll also encounter problems if you move the RAS server into the new domain structure before you enable the new user accounts. The RAS server checks the domain in which it resides for RAS permissions before it tries to verify permissions across trust relationships. If the RAS server encounters a disabled user account, the server denies the user RAS access without looking for further validation. To work around this conflict, leave the RAS server in the old domain structure until you enable the migrated users' accounts. After you enable the accounts in the new domain structure, you can move the RAS server and it will check the old and new domain structures for RAS permissions. This method provides offsite users with the capability to migrate remotely.

NT Workstations
The NT Registry and user environment are significantly more complex than Win9x's Registry and user environment. Therefore, NT workstations present a different set of migration complications.

You can use some of the same tools you used to migrate your servers to migrate your NT workstations. DM/Reconfigure offers features that let you move NT workstations into a new domain structure and convert user profiles. However, these tools require users to be connected to the network when you push out the migration job. In an environment that contains 400 to 500 laptop users, guaranteeing that all users are connected is impossible. Thus, you might need to migrate your NT workstations from one domain to another without using third-party tools.

Migrating the user profile. The user profile is a complex set of Registry parameters, environment variables, files, and settings that define a user's unique working environment. Despite my best efforts, I found no way to automate the migration of user profiles. SIDs identify Registry keys, which complicates exporting and importing the keys. To export Registry keys, you need to know a user's existing SID; to import them, you need to know a user's new SID. Also, you can't simply copy the files in the user's profile to the new domain structure, because the most critical file, ntuser.dat, contains all the information that the user's profile needs and is in use while the profile is in use.

A solution is to copy a user profile with Microsoft's built-in tool, which you run by clicking Copy To on the User Profiles tab in Control Panel's System applet. This utility copies features such as desktop settings, application parameters, and drive mappings. However, this utility has several drawbacks. For example, it won't let you copy a user profile to a user who has never worked on that computer. This limitation means that you can't build a profile in advance for a user you're migrating. You must wait to build the user's profile until after the user has logged on. This method creates a lot of work for users—users have to log on to the new domain, log off, log on to the old domain, copy their profile, log off, and log on again to the new domain. I couldn't find a user who was willing to endure this process. The best solution I found was to instruct users to copy their old profile over the Default User profile on their workstations, so that they have their old profile the next time they log on. The disadvantage of this workaround is that anyone who logs on to a workstation will have to use that workstation's profile as his or her profile template.

Another limitation of the profile copy utility is that the utility copies all of a user's drive mappings. Although this functionality seems advantageous, NT drive mappings use cached credentials (i.e., username and domain) to connect. When users log on to a new domain structure, the credentials that the users supply are different from the cached credentials in the drive mappings; therefore, the mappings fail. To correct this problem, users can disconnect all their drive mappings, or you can write an automated process that disconnects all their drive mappings. I used scripts to parse the existing network connections during the migration and remap the connections after users log on to the new domain structure. I ran the Net Use command and pumped the output to a log file. I then used a Perl script, which Listing 4 shows, to create a standalone batch file from the output log file, disconnect users' drives, and schedule the standalone batch file to reconnect the drives the next time users log on. Although my scripts use Registry exports and imports to extract information from the Registry, you can use Perl's Win32 extensions library to perform the same functions. I didn't choose this option, because the Perl Registry extension library is large and takes a long time to copy to a user's workstation. In addition, the exported Registry keys leave an audit trail that you can manually update and re-import if you have any problems.

The Microsoft Wallet, a feature that Microsoft includes in Internet Explorer (IE) 4.x, further complicates the NT profile copy process. This feature provides a secure storage area in the Registry in which a user can store credit card information for Internet purchases. This area is so secure that even the user can't access it. This configuration causes the profile copy utility to fail and log an unusual error that tells the user The operation completed successfully. You can work around this problem in two ways. First, you can use regedt32 to give a user access to this feature by changing the security permissions on the HKEY_CURRENT_USER SoftwareMicrosoft Protected Storage System Provider Registry key. Alternatively, you can contact Microsoft to obtain the updated sysdm.cpl file, which contains a workaround for this problem. I copied sysdm.cpl to users' workstations and implemented the fix without requiring a reboot.

The final problem I encountered using Microsoft's profile copy utility is that the utility doesn't copy users' environment variables. To work around this problem, modify a user's HKEY_CURRENT_USEREnvironment Registry key, which contains a user's environment variables. Exporting this key from users' old profiles and importing it to users' new profiles ensures that their environment variables follow them to the new domain structure.

Maintaining users' permissions. In my environment, ensuring that users maintain access to their workstations was simple. When the IT technicians built users' workstations, they determined that all users are Local Administrators of their workstations. To ensure that users retained this access after migrating to a new domain structure, I used a script similar to Listing 1. The script I created added the user ID from the new account domain to the Local Administrators group. In my environment, this script was sufficient to ensure that users had the same rights to their workstations as they had had before the migration. In environments in which peer-to-peer networking is prevalent, you might need to convert ACLs on NTFS and share permissions. You can use resource kit utilities such as Subinacl to perform this task.

Remote user migration. When a new user logs on to a workstation, the OS creates a new profile by caching the user's new credentials. To create a new profile, a remote user must select the Login Using Dial-up Networking check box on the NT logon screen. Using this option to connect to the network takes a lot of time. To work around this problem, I modified users' HKEY_LOCAL_MACHINESOFTWARE MicrosoftWindows NTCurrentVersion Winlogon Registry keys by adding the KeepRasConnections string and giving it a value of 1. This modification prevents RAS from dropping the connection when users log off and lets users log on to their existing account, perform the migration, and log on to their account in the new domain without disconnecting from RAS.

Moving On
The final migration challenge is to determine how and when to disable the old accounts and turn off the old domain. I found that automating the process of disabling the old accounts and updating their description fields let me quickly determine which users had migrated. Then I could follow up with the users who hadn't migrated and address their concerns about performing the migration. In addition, I sent email messages alerting users that the days of the old domain were numbered, and I was able to complete the migration project and shut down the old domains. I automated the disabling of accounts in the old domain structure by creating a batch file on an NT server that, in turn, distributed jobs to the domain controller for the users' old domains to disable their accounts. By using a central NT server to distribute the jobs, you enable both NT and Win9x machines to automatically create jobs.

Overall Benefits
A migration project is a lot of work, but after you finish the planning, the implementation is simple, and the benefits to your company are numerous. When you consolidate your domains and reduce the number of required trust relationships, you'll find that implementing centralized network and account administration is easy. In addition, you'll have fewer domain administrators across your network, so security is tighter and easier to enforce. Also, flattening your domain structure ensures an easier transition to Win2K, if you plan to upgrade in the future.