In my last 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 entities.
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 forest.
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 noncontiguous namespaces.
If the domains within a forest don't share a common global catalog, global searches across the forest will not be possible.
Active Directory Forests The schema
The schema, which I described in detail in 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 logically.
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 utility.