Upgrading to Windows Server 2003 : Planning a Windows NT Domain Upgrade (part 2) - Planning the Active Directory Forest

1/26/2012 1:59:28 PM

Planning the Active Directory Forest

There are several steps to take when planning the Active Directory forest for your organization, including designing the Active Directory structure, choosing DNS names, and planning the site topology.

Designing the Active Directory Domain Structure

When designing the Active Directory structure for an existing Windows NT–based network, take into consideration the current Windows NT domain model: single domain, single-master domain, multiple-master domain, or complete trust. (See Table 6-2 for a summary.) This section guides you through designing an Active Directory domain structure appropriate for your existing network model.


When designing your Active Directory structure, start simple. If it’s possible to end up with a single domain, begin with that plan. Explore designs that are more complex than necessary, but go with the simplest design that fits—it’ll be easier to understand, administer, and troubleshoot (especially when you start using Group Policy).

Single-Domain Model

The Windows NT single-domain model consists of a single domain, with all accounts and resources stored together.

The single-domain model is easy to upgrade: the single domain under Windows NT becomes the forest root domain in Active Directory. You can then use OUs to organize the accounts and resources and to delegate some of the administrative burden.

Large domains and networks that might be reorganized at some point should consider creating a dedicated forest root domain (as described in the Real World sidebar “Using Dedicated Forest Roots”), and then upgrading the Windows NT domain as a child domain of the forest root. This requires additional resources and adds some complexity, but not as much as adding a normal domain would.

Single-Master–Domain Model

The Windows NT single-master–domain model consists of one master domain that contains all user accounts, and one or more resource domains that trust the master domain and contain only computer accounts and other resources.

If you have a single-master–domain model, create a dedicated forest root domain (discussed in the Real World sidebar “Using Dedicated Forest Roots”), and make the former master domain the first child domain. Then add the resource domains as second-level child domains.

If the company has a centralized network structure, after upgrading the domains to Active Directory and switching the master domain to Windows 2000 or Windows Server 2003 native mode, consider restructuring the domains into a single child domain. You can use OUs either to mimic the resource domains or to organize them more logically with the accounts and resources grouped and organized according to the company’s structure.


If you want to restructure or consolidate your domains, do so before using Group Policy.

Merging the resource domains back into a single child domain under the dedicated forest root offers a number of advantages. Because there are fewer domains to manage, the administrative burden is less. You can use OUs to create a detailed network structure without dealing with trusts. In addition, you can delegate administrative authority to the OUs, giving you the flexibility to handle the administrative tasks the way you want. You can also perform Active Directory queries faster and more efficiently in a single domain. Finally, because OUs don’t require domain controllers, there is the potential to free up some underused computing resources for other tasks. Figure 1 shows a single-master Windows NT domain converted to an Active Directory tree using a dedicated forest root domain, with a resource domain converted to an OU after switching the account domain to Windows 2000 or Windows Server 2003 native mode.

Figure 1. A single-master Windows NT domain converted to an Active Directory

A company with a more decentralized organization, or one with different business units, might want to keep multiple domains but convert its resource domains into full-fledged domains, with both resources and user accounts. (With Active Directory, there is no reason to keep distinct resource domains.) This arrangement allows users to be in the same domain as the resources they use, reducing traffic and making it easier for users to find and access the resources they need. However, you must wait until you upgrade all relevant domains and switch the target domain to Windows 2000 or Windows Server 2003 native mode before you can move the accounts. This is because an object that is moved between domains loses its ability to access resources to which it formerly had access, unless the native mode SIDHistory feature can provide the resources with the object’s old security identifier (SID).


Third-party solutions can provide much of this organizational flexibility in Windows NT 4.0, with the intent of permitting companies to restructure their domains in a way that works well with Active Directory before they upgrade.

Multiple-Master–Domain Model

The multiple-master–domain model in Windows NT consists of a network with two or more master domains that contain all the user accounts, and multiple resource domains that trust each master domain and contain all the computer accounts and other resources. Large networks use this model to circumvent the Windows NT limit of 40,000 objects per domain.

Because of the flexibility and simplicity the Active Directory single-domain or single global domain models offer, many companies with a multiple-master–domain model choose to consolidate their domains into a single Active Directory domain (with or without a dedicated forest root domain) and use OUs to hierarchically structure their network. If you choose to consolidate the domains, create the forest root domain first (if applicable) and then perform the domain upgrades just as if you were going to preserve the existing domain structure. After you upgrade the domains and switch the target domain to a native-mode functional level, you can move all accounts into the single domain without the need to reassign permissions on the objects.


If you want to restructure or consolidate your domains, do so before using Group Policy.

To create a single-domain tree (with a contiguous namespace) during the domain upgrade, create a dedicated forest root domain and stabilize it with a couple of domain controllers. (See the Real World sidebar “Using Dedicated Forest Roots,” in the previous section.) Then upgrade the master domains one by one, adding them to the Active Directory tree as children of the forest root, which also serves as the tree root domain in this example. Figure 2 shows a multiple-master Windows NT domain converted to an Active Directory tree, with two resource domains converted to OUs after switching the account domains to native mode. After you upgrade the account domains, upgrade the resource domains and add them to the tree as children of the account domains (grandchildren of the forest root). Once the upgrade is complete, switch the account domains to a Windows 2000 or Windows Server 2003 native mode, and consider consolidating the resource domains into the account domains, using OUs when applicable.

Figure 2. A multiple-master Windows NT domain converted to an Active Directory tree

If you want to keep each master domain in an authoritative role, create a multiple-tree forest. First, create a dedicated forest root domain to serve as the root for the forest. Dedicate this domain exclusively to forest administration; do not create your users or resources in this domain. Then seed each master domain as the root for a new tree in the forest. (This is called the tree root domain.) In this case, it doesn’t matter which master domain you upgrade first, but you must upgrade the master domain for each tree before upgrading the resource domains.

Complete-Trust Model

The Windows NT complete-trust model involves multiple domains that all trust each other.

Highly decentralized companies or companies that implemented domains in a piecemeal fashion and gradually connected them often use the Windows NT complete-trust model. The model provides a lot of autonomy and flexibility for each master domain, but it also results in a large administrative burden.

When upgrading an enterprise that uses the complete trust model to Active Directory, many companies try to consolidate their domains into a single tree or even a single domain. If you want to maintain the autonomy of the current domain structure of the complete-trust model, set up each current master domain as a new tree root domain. When you create the Active Directory structure like this, you automatically reduce the amount of administration necessary, as all trusts between domains in an Active Directory tree or forest are automatically transitive. (If this is undesirable, create multiple forests.)

When you upgrade the network, first create the forest root domain, preferably by creating a dedicated forest root. (You could also upgrade an existing domain and seed it as the forest root, although Microsoft discourages this.) When you have the forest root domain up and running with a couple of domain controllers, you can upgrade the account domains and add them as children of the forest root or as roots in new trees. If necessary, after upgrading domains, you can replace any transitive trusts with Windows NT–style one-way trusts to limit access within a forest.


A one-way trust can also be set up to permit a legacy Windows 3.51 or Windows NT 4.0 domain or a child domain of another forest (such as one belonging to a business partner) to access a specific domain in the tree or forest. When you set up an explicit one-way trust in Active Directory, it works identically to trusts in Windows NT—that is, the trust is not transitive. If you grant a domain access to a single domain in the tree or forest, the trusted domain cannot access any other domain in the tree, even though the tree is linked with transitive trusts.

Choosing DNS Names

After conceiving an Active Directory structure, it’s time to name the baby. After you settle on a naming convention and decide whether to use separate internal and external domain names, it’s time to choose the DNS names for the forest root domain and any additional trees. To do so, use the following steps as a guide—just remember that domain names are highly political in nature, so if you’re fond of your job, don’t create the domain structure and namespace without first getting the approval of the authorities in your organization.

Identify what domain names are currently in use with your company. If you use separate domain names for the corporate network and the company’s Internet presence, choose the one in use for the corporate network. This name should be a registered, Internet-valid DNS name so that it’s guaranteed to be unique.

Choose a domain name suffix to use for the forest root domain, and by extension, the entire forest. Windows uses .local by default, but if you plan to include any Mac OS X clients in the forest, choose a different suffix such as .office or .lan. (Note that .local conflicts with the Rendezvous feature of Mac OS X, though there are some workarounds.)

Choose what domain name prefix or full domain name to use for the forest root domain name. This is a crucial decision because the forest root can’t be deleted or easily changed, and if you’re creating a single tree forest, the forest root name (corp.example.local) also serves as the root name for the tree. (Child domains append their names to the front of the root domain name—for example, marketing.corp.example.local.)

This prefix should conform to the following specifications:

  • Not currently in use on the network (if you’re going to use a dedicated forest root domain).

  • Isn’t used on the Internet. It’s fine to use your company’s Internet domain name (for example, example.local). Just remember to add a prefix to it so that local clients don’t get confused trying to access your company Web site (for example, use corp.example.local).

  • Isn’t likely to ever become outdated. (Broad geographical names work well unless you live in Turkey or Russia.)

  • Is 15 characters or fewer, and consists only of Internet standard characters (A-Z, a-z, 0-9, and “-”). This allows legacy clients to use the prefix as the NetBIOS domain name.

  • Is easy to remember and makes sense.

If you’re creating multiple trees, decide what DNS names to use as the root for each tree. Once again, get explicit buy-in from all decision-makers on the project on each of these names because they’re difficult to change and users see them every day.

Arrange to have the forest root DNS prefix ownership, along with the domain names of any additional trees, delegated to the forest administrator, which is likely you. When the actual Active Directory domains are set up or upgraded, you can delegate the ownership of any additional DNS domains to the administrator responsible for DNS in that domain.

Planning the Site Topology

Sites, an important new feature of Active Directory, define the boundaries of LAN connectivity, making WAN links more efficient. When you set up sites that mark the sections of the network that have high-speed symmetrical connectivity (10 Mbps is a good number to use), Active Directory tunes the way it uses the WAN links. It reduces the frequency of replication between sites and directs clients’ service requests, such as client logon events or directory searches, to domain controllers that are available locally.

Sites are independent of domains. Whereas domains typically mirror a company’s logical organizational structure, sites mirror the physical network structure of a company. A single site might consist of one or more domains, trees, or even forests; or a single domain might span multiple sites. A site can consist of a single IP subnet (which is often the case because subnets frequently mark physical network boundaries) or multiple IP subnets, but all subnets must share reliable, high-speed connectivity to be a part of a single site.


It is becoming increasingly common for a company’s WAN link to be as fast as an internal LAN. However, the WAN link charge might be based on usage, or a company might use the link heavily for real-time, bandwidth-intensive tasks such as video, reducing the available bandwidth. In such cases, you might still want to set up a site structure for the Active Directory forest to avoid burdening the WAN link with excessive replication and service requests.

When planning to upgrade a Windows NT domain to Active Directory, it is important to plan the site topology so that you can set up the site structure promptly after upgrading. Ask yourself the following questions and record your answers:

What sites do you need to create in the Active Directory forest?
What links are available between these sites, and how fast and expensive are they? Are they already heavily utilized, or is an abundance of bandwidth available?
Are you planning to create additional links between the sites?
Are there any domains that span physical sites, and if so, are the links between the sites fast enough to support this?


Sites are easy to reconfigure, so be sure to tune them as your network links change.

Two types of connections are available for intersite replication: point-to-point synchronous low-speed remote procedure call (RPC) and Simple Mail Transfer Protocol (SMTP). Any domains that span multiple sites must have at least a point-to-point synchronous low-speed RPC connection between the sites within the domain. This connection is required because you can’t use SMTP for intersite replication between domain controllers in the same domain; you can use SMTP links only for schema, configuration, and global catalog (GC) information replication. Therefore, if you have multisite domains, double-check the link between the sites to make sure you have adequate connectivity for this setup.

You would be wise to have a global catalog server on each site to allow a local domain controller to service requests for any resource in the forest without having to use the WAN link. However, the global catalog server shouldn’t be the same server as the infrastructure master unless there are no other domain controllers in the domain, because this configuration breaks the infrastructure master’s ability to update other domain controllers in the domain.

Place at least one DNS server in each site, and have a minimum of two domain controllers per site for redundancy. (This isn’t as important for remote sites with a small number of clients.)


Place at least one Windows Server 2003 domain controller in each site. Doing so allows Windows Server 2003 to take over the topology generator role, improving intersite replication efficiency and scalability, even when the rest of the domain controllers are running Windows 2000. Switching to Windows Server 2003 functional level results in additional efficiency and scalability improvements, including automatically selecting bridgehead servers and allowing the maximum number of sites per domain to increase to 3000. (The limit is 300 otherwise.)

  •  Upgrading to Windows Server 2003 : Architectural Changes Since Windows NT 4.0
  •  Windows Server 2008 R2 monitoring and troubleshooting : Event Viewer - Configuring event-based tasks & Setting up event log forwarding
  •  Windows Server 2008 R2 monitoring and troubleshooting : Performance Monitoring
  •  Working with the windows 7 common file dialogs (part 3) - Defining a File Save Dialog
  •  Working with the windows 7 common file dialogs (part 2) - Defining a File Open Dialog
  •  Working with the windows 7 common file dialogs (part 1)
  •  Programming Excel with VBA and .NET : Variables (part 4) - User-Defined Types & Objects
  •  Programming Excel with VBA and .NET : Variables (part 3) - Constants, Enumerations & Arrays
  •  Programming Excel with VBA and .NET : Variables (part 2) - Conversions, Scope and Lifetime
  •  Programming Excel with VBA and .NET : Variables (part 1) - Names & Declarations
  •  Windows Vista : Performing Local PC Administration (part 2) - Performing common workstation administration tasks
  •  Windows Vista : Performing Local PC Administration (part 1) - Working with workstation administration tools
  •  Filtering Out Evil with Firewalls (part 3) - Manually Configuring a Firewall's Ports
  •  Filtering Out Evil with Firewalls (part 2)
  •  Filtering Out Evil with Firewalls (part 1)
  •  Windows 7 : Windows Driver Foundation Architecture (part 4) - Tools for Development and Testing
  •  Windows 7 : Windows Driver Foundation Architecture (part 3) - Driver Frameworks
  •  Windows 7 : Windows Driver Foundation Architecture (part 2) - Integrated I/O Queuing and Cancellation
  •  Windows 7 : Windows Driver Foundation Architecture (part 1)
  •  Windows 7 : Using Advanced Security Options (part 2) - Configuring Windows Defender
    Top 10
    Smartphone HTC Desire C - Yet Shrunken Down
    Audioengine W3 Wireless DAC Review
    KWA 150 SE – The Most Expensive Amplifier Of ModWright
    Olive 06HD Player For Audiophiles
    Pioneer HTIB Surround Sound Systems With Prices Ranging From $360
    Windows Vista : Scripting and Automation - Command Prompt Scripting (part 3)
    Windows Vista : Scripting and Automation - Command Prompt Scripting (part 2)
    Windows Vista : Scripting and Automation - Command Prompt Scripting (part 1) - DOS Commands, Batch Files
    Windows Vista : Scripting and Automation - Wacky Script Ideas
    Windows 7 : Programming Drivers for the User Mode Driver Framework - Required Driver Functionality, UMDF Sample Drivers
    Most View
    Exploiting SQL Injection : Automating SQL Injection Exploitation
    iPhone 3D Programming : Adding Textures to ModelViewer (part 1) - Enhancing IResourceManager
    Windows Server 2008 : DHCP/WINS/Domain Controllers - Enhancing DHCP Reliability
    Windows Phone 7 Development : Understanding Trial and Full Modes (part 3) - Simulating Application Trial and Full Modes
    iPhone Application Development : Getting the User’s Attention - Generating Alerts
    In Search Of The Perfect Mid-Tower (Part 1) - Antec Eleven Hundred, Silverstone Temjin Tj04-E
    Case Modding: simple case modding techniques
    Preparing Your Windows 8 PC : Connecting to Wireless Networks
    Server-Side Browser Detection and Content Delivery : Mobile Detection (part 4) - Device Libraries
    Logitech S715i iPhone - iPod Dock
    Lenovo ThinkCentre Edge 91z - Centre Of Thought
    Windows Server 2003 : Using Backup - Planning for Failure, Handling Backup and Restore Problems, Third-Party Backup Utilities
    Oloneo HDRengine
    iPhone Application Development : Building a Multi-View Tab Bar Application (part 1)
    Becoming an Excel Programmer : Navigate Samples and Help
    Strip HTML of Tags
    Handling Mobile User Input (part 3) - Building the UFO 2 Example
    Windows Server 2008 : Domain Name System and IPv6 - Other DNS Components
    Windows Vista : Make Your Hardware Perform (part 1) - Get Glass
    Moving a Dynamic Disk to a New System