Determining the Number of Domains in Each Forest

To determine the number of domains that you will have in each forest, start by considering a single domain only, even if you currently have more than one Windows NT 4.0 domain. Next, provide a detailed justification for each additional domain. Every domain that you create will introduce some incremental cost in terms of additional management overhead. For that reason, be certain that the domains you add to a forest serve a beneficial purpose.

How Creating Domains Has Changed

Some of the factors that lead to the creation of multiple domain environments in previous versions of Windows NT Server no longer apply to Active Directory and Windows 2000. These factors are as follows:

Security Accounts Manager (SAM) Size Limitations    In previous versions of Microsoft® Windows NT® Server, the SAM database had a practical limitation of about 40,000 objects per domain. Active Directory can scale easily to millions of objects per domain. It should never be necessary to create additional domains in order to handle more objects.

Primary Domain Controller (PDC) Availability Requirements    In previous versions of Windows NT Server, only a single domain controller, the PDC, could accept updates to the domain database. In an organization with a large network, this limitation made it difficult to ensure high availability of the PDC, because a network outage could prevent administrators on one part of the network from being able to update the domain. To satisfy the availability requirement, you created additional domains so that PDC servers could be distributed throughout the network. This is no longer necessary in Windows 2000, because all Active Directory domain controllers can accept updates.

Limited Delegation of Administration Within a Domain    In previous versions of Windows NT Server, you delegated administration using built-in local groups such as the Account Operators group, or by creating multiple domains and having distinct sets of domain administrators. For example, to delegate the management of a set of users, you created a new user domain. To delegate management of resource servers like file or print servers you created resource domains. In Windows 2000, it is possible to delegate administration within a domain using organizational unitsI> (OUs). s a container that you use to organize objects within a domain into logical administrative subgroups. OUs are easier to create, delete, move, and modify than domains, and they are better suited to the delegation role.

For more information about using OUs to delegate administration, see "Creating an Organizational Unit Plan" later in this chapter.

When to Create More Than One Domain

Three possible reasons for creating additional domains are:

  • Preserving existing Windows NT  domains.

  • Administrative partitioning.

  • Physical partitioning.

Preserving Existing Windows NT Domains

If you already have Windows NT domains in place today, you might prefer to keep them as they are instead of consolidating them into a smaller number of Active Directory domains. If you decide to keep or consolidate a domain, be sure to weigh those costs against the long-term benefits of having fewer domains. The costs associated with domain consolidation are discussed in the chapter "Determining Domain Migration Strategies" in this book. If this is your first time through domain design, it is recommended that you aim for the fewest domains possible, and reevaluate this plan after reading that chapter.

Administrative Partitioning

More domains might be necessary depending on the administrative and policy requirements of your organization, described as follows.

Unique domain user security policy requirements    You might want to have a set of users on your network abide by a domain user security policy that is different from the security policy applied to the rest of the user community. For example, you might want your administrators to have a stronger password policy, such as a shorter password change interval, than the regular users on your network. To do this, you must place those users in a separate domain.

Division requires autonomous domain administration supervision    The members of the domain administrators group in a particular domain have complete control over all objects in that domain. If you have a subdivision in your organization that will not allow outside administrators control over their objects, place those objects in a separate domain. For example, for legal reasons, it might not be prudent for a subdivision of an organization that works on highly sensitive projects to accept domain supervision from a higher level IT group. Remember that all domains in the forest must share the Configuration and Schema containers.

Physical Partitioning

Physical partitioning involves taking the domains you have in a forest and dividing them up into a greater number of smaller domains. Having a greater number of smaller domains allows you to optimize replication traffic by only replicating objects to places where they are most relevant. For example, in a forest containing a single domain, every object in the forest is replicated to every domain controller in the forest. This might lead to objects being replicated to places where they are rarely used, which is an inefficient use of bandwidth. For example, a user that always logs on at a headquarters location does not need their user account replicated to a branch office location. Replication traffic can be avoided by creating a separate domain for the headquarters location and not replicating that domain to the branch office.

note-iconNote

If you have already deployed Windows NT 4.0 domains, you might be satisfied with your existing physical partitioning. Looking at partitioning again from a clean sheet can help you identify areas for possible domain consolidation. If you have already decided to upgrade your Windows NT 4.0 domains in place and not perform any consolidation, you can skip the partitioning discussion.

To determine if, and how, to partition a forest, you should:

  • Draw your network topology.

  • Place domain controllers in the network according to availability requirements.

  • Partition the forest based on the replication traffic between domain controllers.

Draw Your Network Topology

Begin by drawing a basic network topology diagram. Later in the planning process you will add more detail to this diagram when you plan your site topology. To create the topology diagram:

  • Draw collections of sites. A site is a network of fast, reliable connectivity. A local area network (LAN) or set of LANs connected by a high-speed backbone can be considered a site. Draw each site on your network diagram and indicate the approximate number of users at the site.

  • Connect sites with site links. A site link is a slow or unreliable link that connects two sites. A wide area network (WAN) that connects two fast networks is an example of a site link. It is recommended you treat any link that is slower than LAN speed as a slow link. On the topology diagram, show how each site connects to other sites with site links. For each site link, record the following:

    • Link speed and current usage levels

    • Whether the link is pay-by-usage

    • Whether the link is historically unreliable

    • Whether the link is only intermittently available

  • Mark sites with SMTP connectivity only. If you have a site that has no physical connection to the rest of your network but can be reached via Simple Mail Transfer Protocol (SMTP) mail, mark that site as having mail-based connectivity only.

Figure 9.3 shows the network topology for the fictitious Reskit company.

Cc960561.DGBD_20(en-us,TechNet.10).gif

Figure 9.4 Reskit Company Domain Controller Placement

Partition the Forest

Now you will assign a domain to each domain controller, determine if your network can handle the replication traffic, and partition your forest into smaller domains if necessary. While doing this, remember that the objective of partitioning is to put physical copies of directory objects near the users that need those objects. For example, a user's user account object needs to be located on a domain controller that is in the same site as the user.

To partition the forest, perform the following steps for each domain currently in the domain plan:

  • For each site that contains a domain controller, decide if the domain is relevant to the users in the site. If appropriate, place a domain controller for the domain into the site.

  • Trace the path that replication will follow between domain controllers for the domain. Assume that each domain controller will choose the next nearest domain controller for the same domain as a replication partner, where "nearest" is determined by the most cost-effective path through the network.

  • The volume of replication traffic between any two domain controllers for a domain is a factor of how often the objects in the domain change, how many of them change, and how often objects are added and deleted. By splitting a domain into two or more smaller domains, you can decrease the amount of replication traffic that will travel over a particular link. Examine each edge in the replication path and decide if you will permit the replication traffic or split the domain.

Consider these factors when deciding whether or not to replicate a domain between sites, or to split it into two or more smaller domains:

  • Consider splitting the domain if a site link in the replication path cannot accommodate the anticipated replication traffic. The actual capacity of a site link is a function of link speed, daily usage characteristics, reliability, and availability. Consider the following information about a link when deciding whether to create a domain:

    • A link operating near capacity might not be able to accommodate replication. Keep in mind that Active Directory replication can be scheduled, so if the link has idle periods during the day, there might be enough actual bandwidth for replication to keep up.

    • A link might only be available during certain times of day, lowering its actual bandwidth. Active Directory replication can be scheduled to occur only when the link is available, but the actual bandwidth must be high enough to accommodate replication.

    For more information about network capacity planning and Active Directory replication traffic, see the Microsoft Windows 2000 Server link on the Web Resources page at https://windows.microsoft.com/windows2000/reskit/webresources.

  • Consider splitting the domain if you do not want replication traffic to compete with other, more important traffic on a link. Interrupting or delaying business-critical traffic might be much more costly than adding an additional domain.

  • Consider splitting the domain if replication traffic will cross a pay-by-usage link. When a link is pay-by-usage, minimizing usage will minimize your costs.

  • Create domains for sites that are connected by SMTP mail only. Active Directory mail-based replication can only occur between domains. Mail-based replication cannot be used between domain controllers of the same domain.

If you do decide to split a large domain into several smaller domains, a good strategy for creating the smaller domains is to base them on geography or geo-political boundaries. For example, create domains that map to countries, regions or continents. Geographical mapping for domains is recommended because network topologies tend to map to geographical locations, and geography tends to change less than any other basis for divisions.

You might want to create a greater number of smaller domains simply to optimize replication traffic on your network. Remember, optimization is a tradeoff against other factors, such as:

  • Complexity As discussed earlier, each additional domain introduces a fixed on-going management overhead.

  • Query traffic versus replication traffic The fewer the number of objects in a domain, the more likely a user in that domain will want to access objects that are in some other domain. If there is no local domain controller for the other domain, the query will cause traffic to leave the site.

note-iconNote

A model with a single large domain works best with a large roaming user population because every user account will be available in every site that has a domain controller. In this case, a roaming user will never lose the ability to log on if a network outage occurs between the user's current location and home location.

Figure 9.5 shows the physical partitioning for the Reskit company. The domain assignments are as follows:

  • The Noam domain for users in North America is assigned to a domain controller in the home site.

  • The Avionics domain, which was created for administrative reasons, is assigned to a domain controller in the home site since there are Avionics users at headquarters.

  • A new domain, Eu, is assigned to a domain controller in the European operations center because the transoceanic WAN link is near capacity. The link cannot handle the replication traffic for both the North American and European domains combined.

  • The Avionics domain is also represented in the European Operations center, since there are Avionics users in Europe.

  • A new domain, Seville, is assigned to a domain controller in the regional office in Seville because the WAN link back to the European operations center is carrying business-critical traffic.

  • A new domain, Mfg, is assigned to a domain controller in the manufacturing plant because it can only be accessed by SMTP mail.

Cc960561.DGBD_22(en-us,TechNet.10).gif

Figure 9.5 Reskit Company Domain Assignment

Incremental Costs for an Additional Domain

Each domain in the forest will introduce some amount of management overhead. When debating whether or not to add a domain to your domain plan, weigh the following costs against the benefits you determined earlier in the chapter.

More Domain Administrators    Because domain administrators have full control over a domain, the membership of the domain administrators group for a domain must be closely monitored. Each added domain in a forest incurs this management overhead.

More Domain Controller Hardware    In Windows 2000, a domain controller can host only a single domain. Each new domain that you create will require at least one computer, and in most cases will require two computers to meet reliability and availability requirements. Because all Windows 2000 domain controllers can accept and originate changes, you must physically guard them more carefully than you did Windows NT 4.0 backup domain controllers (BDCs), which were read-only computers. Note that the administration delegation within Active Directory domains reduces the requirement for resource domains. Some remote locations that currently must host two domain controllers (a master user domain and a local resource domain) will now only require one domain controller if you choose to consolidate to fewer Active Directory domains.

More Trust Links    For a domain controller in one domain to authenticate a user from another domain, it must be able to contact a domain controller within the second domain. This communication represents an added possible point of failure if, for example, the network between the two domain controllers is malfunctioning at the time. The more users and resources located in a single domain, the less an individual domain controller must rely on being able to communicate with other domain controllers to maintain service.

Greater Chance of Having to Move a Security Principal Between Domains    The more domains you have, the greater the chance you have to move security principals, such as users and groups, between two domains. For example, a business reorganization or a job change for a user can create the need to move a user between domains. To end users and administrators, moving a security principal between OUs inside a domain is a trivial and transparent operation. However, moving a security principal between domains is more involved and can impact the end user.

For more information about moving security principals between domains, see "Determining Domain Migration Strategies" in this book.

Group Policy and Access Control Do Not Flow Between Domains    Group Policy and access control applied within a domain do not flow automatically into other domains. If you have policies or delegated administration through access control that is uniform across many domains, they must be applied separately to each domain.