Flatten Your NT 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.

   Previous  [1]  2  Next