When deploying Exchange 2007 in your
environment, Active Directory is a critical component. Exchange 2007
uses the Active Directory directory service to store and share directory
information with Microsoft Windows.
If you have already deployed Active Directory
into your environment, it is important that you have a solid
understanding of your existing implementation and how Exchange will fit
into your structure. If you have not deployed AD, you need to design the
environment with your Exchange environment in mind.
In addition, you need to evaluate your
organization’s administrative model, as the marriage of Exchange 2007
and AD allows you to administer Exchange along with the operating
system.
When integrating Exchange 2007 and
Active Directory, the placement domain controllers and global catalog
servers is paramount; without proper placement of these key items, your
Exchange environment will not be able to perform optimally.
The remainder of this chapter discusses these
items and offers troubleshooting techniques for directory access
problems. In addition, best-practice recommendations are offered for the
placement of domain controllers and global catalog servers.
Understanding Active Directory Structure
Active Directory (AD) is a standards-based LDAP
directory service developed by Microsoft that stores information about
network resources and makes it accessible to users and applications,
such as Exchange 2007. Directory services are vital in any network infrastructure because they provide a way to name, locate, manage, and secure information about the resources contained.
The Active Directory directory service provides
single-logon capability and a central repository for the information for
your entire organization. User and computer management are greatly
simplified and network resources are easier than ever to access.
In addition, Active Directory is heavily
utilized by Exchange, and stores all of your Exchange attributes: email
addresses, mailbox locations, home servers, and a variety of other
information.
Exploring AD Domains
An Active Directory domain is the main logical
boundary of Active Directory. In a standalone sense, an AD domain looks
very much like a Windows NT domain. Users and computers are all stored
and managed from within the boundaries of the domain. However, several
major changes have been made to the structure of the domain and how it
relates to other domains within the Active Directory structure.
Domains in Active Directory serve as a security
boundary for objects and contain their own security policies. For
example, different domains can contain different password policies for
users. Keep in mind that domains are a logical organization of objects
and can easily span multiple physical locations. Consequently, it is no
longer necessary to set up multiple domains for different remote offices
or sites because replication concerns can be addressed with the proper
use of Active Directory sites, which are described in greater detail
later in this chapter.
Exploring AD Trees
An Active Directory tree is composed of multiple
domains connected by two-way transitive trusts. Each domain in an
Active Directory tree shares a common schema and global catalog. The
transitive trust relationship between domains is automatic, which is a
change from the domain structure of NT 4.0, wherein all trusts had to be
manually set up. The transitive trust relationship means that because
the asia domain trusts the root companyabc domain, and the europe domain trusts the companyabc domain, the asia domain also trusts the europe domain. The trusts flow through the domain structure.
Exploring AD Forests
Forests are a group of interconnected domain trees. Implicit trusts connect the roots of each tree into a common forest.
The overlying characteristics that tie together
all domains and domain trees into a common forest are the existence of a
common schema and a common global catalog. However, domains and domain
trees in a forest do not need to share a common namespace. For example,
the domains microsoft.com and msnbc.com could theoretically be part of the same forest, but maintain their own separate namespaces (for obvious reasons).
Note
Each
separate instance of Exchange Server 2007 requires a completely
separate AD forest. In other words, AD cannot support more than one
Exchange organization in a single forest. This is an important factor to
bear in mind when examining AD integration concepts.
Understanding AD Replication with Exchange Server 2007
An understanding of the relationship between
Exchange and Active Directory is not complete without an understanding
of the replication engine within AD itself. This is especially true
because any changes made to the structure of Exchange must be replicated
across the AD infrastructure.
Active Directory replaced the concept of
Primary Domain Controllers (PDCs) and Backup Domain Controllers (BDCs)
with the concept of multiple domain controllers that each contains a
master read/write copy of domain information. Changes that are made on
any domain controller within the environment are replicated to all other
domain controllers in what is known as multimaster replication.
Active Directory differs from most directory
service implementations in that the replication of directory information
is accomplished independently from the actual logical directory design.
The concept of Active Directory sites is completely independent from
the logical structure of Active Directory forests, trees, and domains.
In fact, a single site in Active Directory can actually host domain
controllers from different domains or different trees within the same
forest. This enables the creation of a replication topology based on
your WAN structure, and your directory topology can mirror your
organizational structure.
From an Exchange point of view, the most
important concept to keep in mind is the delay that replication causes
between when a change is made in Exchange and when that change is
replicated throughout the entire AD structure. The reason for these
types of discrepancies lies in the fact that not all AD changes are
replicated immediately. This concept is known as replication latency.
Because the overhead required in immediately replicating change
information to all domain controllers is large, the default schedule for
replication is not as often as you might want. To immediately replicate
changes made to Exchange or any AD changes, use the following
procedure:
1. | Open Active Directory Sites and Services.
|
2. | Drill down to Sites, sitename, Servers, servername,
NTDS Settings. The server name chosen should be the server you are
connected to, and from which the desired change should be replicated.
|
3. | Right-click each connection object and choose Replicate Now, as illustrated in Figure 1.
|