Active
Directory Domain Services (AD DS), often referred to simply as Active
Directory (AD), is a necessary and fundamental component of any Exchange
Server 2010 implementation. That said, organizations do not necessarily
need to panic about setting up Active Directory in addition to Exchange
Server, as long as a few straightforward design steps are followed. The
following areas of Active Directory must be addressed to properly
design and deploy Exchange Server 2010:
Forest and domain design
AD site and replication topology layout
Domain controller and global catalog placement
Domain name system (DNS) configuration
Understanding Forest and Domain Design
Because
Exchange Server 2007 uses Active Directory for its underlying directory
structure, it is necessary to link Exchange Server with a unique Active
Directory forest.
In many cases, an
existing Active Directory forest and domain structure is already in
place in organizations considering Exchange Server 2010 deployment. In
these cases, Exchange Server can be installed on top of the existing AD
environment, and no additional AD design decisions need to be made. It
is important to note that Exchange Server 2010 requires that the AD
forest be at least at Windows Server 2003 functional level and also
requires that at least one Windows Server 2003 SP2 or Windows Server
2008 RTM/R2 Global Catalog is installed in each AD site in which
Exchange servers reside. Finally, the schema master for the forest must
be either a Windows Server 2003 SP2 or Windows Server 2008 (RTM or R2)
domain controller.
In some cases, there
might not be an existing AD infrastructure in place, and one needs to be
deployed to support Exchange Server. In these scenarios, design
decisions need to be made for the AD structure in which Exchange Server
will be installed. In some specific cases, Exchange Server might be
deployed as part of a separate forest by itself, as illustrated in Figure 1.
This model is known as the Exchange Resource Forest model. This is
often the case in an organization with multiple existing AD forests.
In any case, AD
should be designed with simplicity in mind. A single-forest,
single-domain model, for example, solves the needs of many
organizations. If Exchange Server itself is all that is required of AD,
this type of deployment is the best practice to consider.
Note
The addition of
Exchange Server 2010 into an Active Directory forest requires an
extension of the AD forest’s Active Directory schema.
Considerations for this factor must be taken into account when deploying Exchange Server onto an existing AD forest.
Microsoft
has gotten serious recently about support for Exchange Server across
multiple forests. This was previously an onerous task to set up, but the
ability to synchronize between separate Exchange Server organizations
has been simplified through the use of Identity Lifecycle Manager (ILM)
2007. ILM now comes with a series of preconfigured scripts to replicate
between Exchange Server forests, enabling organizations that, for one
reason or another, cannot use a common forest to unite the email
structure through object replication.
Outlining AD Site and Replication Topology Layout
Active Directory
sites should mirror existing network topology. Where there are pools of
highly connected AD domain controllers, for example, Active Directory
sites should be created to optimize replication. Smaller organizations
have the luxury of a simplified AD site design. In general, the number
of sites is small—or, in most cases, composed of a single physical
location. Midsize and larger organizations might require the creation of
multiple Active Directory sites to mirror the wide area network (WAN)
connectivity of the organization.
Exchange Server 2010 no
longer uses a separate replication mechanism (routing groups) from
Active Directory, and Exchange Server replication takes place within the
context of Active Directory sites. This makes proper AD site topology
creation a critical component of an Exchange Server deployment.
Reviewing Domain Controller and Global Catalog Placement Concepts
In small or
midsize organizations, you have effectively two options regarding domain
controller placement. The first option involves using the same physical
server for domain controller and Exchange Server duties. This option is
feasible, though not recommended, for smaller organizations if budget
constraints preclude the addition of more than one server. This type of
deployment strategy is not feasible for mid-sized and enterprise
organizations, however, and the domain controller functions should be
separated onto dedicated systems.
Configuring DNS
Because AD
and Exchange Server are completely dependent on DNS for lookups and
overall functionality, configuring DNS is an important factor to
consider. As a common AD best practice, DNS is installed on the domain
controller(s), which enables the creation of Active Directory–integrated
DNS zones. AD–integrated zones enable DNS data to be stored in AD with
multiple read/write copies of the zone available for redundancy
purposes. Although using other non-Microsoft DNS for AD is supported, it
is not recommended.
The main decision
regarding DNS layout is the decision about the namespace to be used
within the organization. The DNS namespace is the same as the AD domain
information, and it is difficult to change later. The two options in
this case are to configure DNS to use either a published, external
namespace that is easy to understand, such as cco.com, or an internal, secure namespace that is difficult to hack into, such as cconet.internal. In general, the more security-conscious an organization, the more often the internal namespace will be chosen.
