Understanding Active Directory, Part 2
column we began our discussion of Window's 2000's Active Directory (AD), with an
overview of some of AD's critical components. This week we continue to explore AD's
structure, looking at forests, sites, and replication.
Objects, OUs, domains, and trees
AD, like all other directory services, is a database that centralizes the data and
instructions that user applications need to communicate over a network. As I discussed
in Part 1, the basic unit of AD is the object. Objects are typically maintained in
organizational units (OUs), which are in turn maintained in one or more domains.
When you create multiple domains containing the same domain name -- for example,
Domain.com, Dev.domain.com, HR.domain.com, etc. -- you begin to build a tree. All
domains within a tree share the same configuration (which defines the AD settings) and
global catalog (which facilitates global searches). By using trees to structure your
network, you can logically break out your enterprise into separate, manageable
If your organization needs to maintain separate namespaces, for example because of a
merger or acquisition, each namespace can be managed separately by creating a
A forest is a collection of domains that have noncontiguous namespaces but that
share a common schema, configuration, and global catalog. (Having a noncontiguous
namespace means that domains don't share a common domain name.) Domains within a forest
are linked via two-way transitive trusts.
For example, say you create a forest that includes the domains Abigo.com and
Merger.com (see figure, below). Because they're part of the same forest, the two
domains share the same schema, configuration, and global catalogs even though they have
If the domains within a forest don't share a common global catalog, global searches
across the forest will not be possible.
The schema, which I described in detail in HREF="http://www.itworld.com/Net/1746/ITW729/">Part 1 of
this series, lists definitions of all the objects within a forest. All domains within a
tree share a common schema, as do all trees in the same forest. If they don't share a
common schema, objects can exist in one section of the forest, but not in others.
Now let's talk about sites. The formal definition of a site is one or more well-
connected IP subnets. (Well-connected subnets, usually located in the same facility,
building, etc., are defined as connecting at speeds of 10 Mbs or higher.)
When your network is composed of sites, Active Directory can understand the design of
its underlying infrastructure -- where it's segmented and where slow links are. With
this information, AD can decide how to replicate data.
You may be asking yourself, what is the difference between a site and a domain?
Basically, sites constitute your physical network, while domains represent your network
Say your company has multiple locations worldwide. Even though all the offices
manage their own networks locally, they're still part of the same parent company. You
could logically split up the companywide network into multiple domains, each
representing one location.
When your network is composed of sites, AD can both automatically configure its
replication topology (which you can do manually yourself as well) and aid clients in
locating domain controllers (DCs) for logon authentication. (Users' requests are always
directed to the domain controllers within their site.)
One of the major uses of sites is to facilitate AD's control of replication.
Replication is the process of copying data from one source to multiple destinations to
keep the data synchronized. For example, when you change a person's name on one domain
controller, other DCs will see the name's old value until replication has taken place.
Once replication occurs, all DCs will have the new name in place. Replication is a very
technical topic that I will cover in depth in later articles.
In my next article, we will install Active Directory using the DCPROMO