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.
Note
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.
Note
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.
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).
Note
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.
Note
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.
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.
Note
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.
1. | 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.
|
2. | 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.)
|
3. | 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.
|
4. | 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.
|
5. | 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.
Note
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? |
Note
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.)
Note
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.)
