1. Designing Active Directory for Exchange Server 2013
Active
Directory (AD) is a necessary and fundamental component of any Exchange
Server 2013 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 2013:
• 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 2013 uses Active Directory Domain Services (AD DS) for
its underlying directory structure, it is necessary to link Exchange
Server with a single AD DS forest.
In many
cases, an existing AD DS forest and domain structure is already in
place in organizations considering Exchange Server 2013 deployment. In
these cases, Exchange Server can be installed on top of the existing AD
environment, and no additional AD DS design decisions need to be made.
It is important to note that Exchange Server 2013 requires that the AD
DS forest be at least at Windows Server 2003 functional level and also
requires that at least one Windows Server 2003 SP2 or later global
catalog is installed in each AD DS site in which Exchange servers
reside. Finally, the schema master for the forest must be Windows
Server 2003 SP2 or later.
In some cases,
there might not be an existing AD DS 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 DS 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
sometimes the case in an organization with multiple existing AD forests.
Figure 1. Understanding the Exchange Resource Forest model.
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 DS, this type of deployment is the best practice to consider.
Note
The addition of Exchange Server 2013 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.
Outlining AD DS Site and Replication Topology Layout
AD
DS sites should mirror existing network topology. Where there are pools
of highly connected AD DS domain controllers, for example, AD DS sites
should be created to optimize replication. Smaller organizations have
the luxury of a simplified AD DS 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 AD DS sites to mirror the wide area network (WAN)
connectivity of the organization.
Exchange
Server 2013 no longer uses a separate replication mechanism (routing
groups) from AD DS, and Exchange Server replication takes place within
the context of Active Directory sites. This makes proper AD DS 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
midsize and enterprise organizations, however, and the domain
controller functions should be separated onto dedicated systems.
Configuring DNS
Because
AD DS 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 DS 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
DS 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 DS 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 in to, such as cconet.internal.
In general, the more security-conscious an organization, the more often
the internal namespace will be chosen. This, however, is a dated
concept.
Creating
a split-brain DNS architecture, where the same DNS zone is used
internally as well as externally, such as companyabc.com, is strongly
recommended because it will greatly simplify the creation and
management of Secure Sockets Layer (SSL) certificates because few
public certificate authorities will add internal domains to
certificates. In a split-brain arrangement, hostnames are entered in
DNS to point to internal IP addresses, while the same entries in
external DNS point to the Internet addresses. The external DNS zone
needs only to contain hosts that are referenced from outside the
network.
