After
all objectives, dependencies, and requirements have been mapped out,
the process of designing the Exchange Server 2010 environment can begin.
Decisions should be made in the following key areas:
Understanding the AD Forest
Because Exchange Server
2010 relies on the Windows Server 2008 AD for its directory, it is
therefore important to include AD in the design plans. In many
situations, an AD implementation, whether based on Windows 2000 Server,
Windows Server 2003, or Windows Server 2008, AD already exists in the
organization. In these cases, it is necessary only to plan for the
inclusion of Exchange Server into the forest.
Note
Exchange Server 2010
has several key requirements for AD. First, all domains and the forest
must be at Windows Server 2003 functional levels or higher. Second, it
requires that at least one domain controller in each site that includes
Exchange Server be at least Windows Server 2003 SP2 or Windows Server
2008.
If an AD structure is not
already in place, a new AD forest must be established. Designing the AD
forest infrastructure can be complex, and can require nearly as much
thought into design as the actual Exchange Server configuration itself.
Therefore, it is important to fully understand the concepts behind AD
before beginning an Exchange Server 2010 design.
In short, a single
“instance” of AD consists of a single AD forest. A forest is composed of
AD trees, which are contiguous domain namespaces in the forest. Each
tree is composed of one or more domains, as illustrated in Figure 1.
Certain cases exist for using more than one AD forest in an organization:
Political limitations—
Some organizations have specific political reasons that force the
creation of multiple AD forests. For example, if a merged corporate
entity requires separate divisions to maintain completely separate
information technology (IT) infrastructures, more than one forest is
necessary.
Security concerns—
Although the AD domain serves as a de facto security boundary, the
“ultimate” security boundary is effectively the forest. In other words,
it is possible for user accounts in a domain in a forest to hack into
domains within the same forest. Although these types of vulnerabilities
are not common and are difficult to do, highly security-conscious
organizations should implement separate AD forests.
Application functionality—
A single AD forest shares a common directory schema, which is the
underlying structure of the directory and must be unique across the
entire forest. In some cases, separate branches of an organization
require that certain applications, which need extensions to the schema,
be installed. This might not be possible or might conflict with the
schema requirements of other branches. These cases might require the
creation of a separate forest.
Exchange-specific functionality (resource forest)—
In certain circumstances, it might be necessary to install Exchange
Server 2010 into a separate forest, to enable Exchange Server to reside
in a separate schema and forest instance. An example of this type of
setup is an organization with two existing AD forests that creates a
third forest specifically for Exchange Server and uses cross-forest trusts to assign mailbox permissions.
The simplest designs
often work the best. The same principle applies to AD design. The
designer should start with the assumption that a simple forest and
domain structure will work for the environment. However, when factors
such as those previously described create constraints, multiple forests
can be established to satisfy the requirements of the constraints.
Understanding the AD Domain Structure
After the AD
forest structure has been chosen, the domain structure can be laid out.
As with the forest structure, it is often wise to consider a single
domain model for the Exchange Server 2010 directory. In fact, if
deploying Exchange Server is the only consideration, this is often the
best choice.
There is one major
exception to the single domain model: the placeholder domain model. The
placeholder domain model has an isolated domain serving as the root
domain in the forest. The user domain, which contains all production
user accounts, would be located in a separate domain in the forest, as
illustrated in Figure 2.
The placeholder
domain structure increases security in the forest by segregating
high-level schema-access accounts into a completely separate domain from
the regular user domain. Access to the placeholder domain can be
audited and restricted to maintain tighter control on the critical
schema. The downside to this model, however, is the fact that the
additional domain requires a separate set of domain controllers, which
increases the infrastructure costs of the environment. In general, this
makes this domain model less desirable for smaller organizations because
the trade-off between increased cost and less security is too great.
Larger organizations can consider the increased security provided by
this model, however.
Reviewing AD Infrastructure Components
Several
key components of AD must be installed within an organization to ensure
proper Exchange Server 2010 and AD functionality. In smaller
environments, many of these components can be installed on a single
machine, but all need to be located within an environment to ensure
server functionality.
Outlining the Domain Name System (DNS) Impact on Exchange Server 2010 Design
In addition to being
tightly integrated with AD, Exchange Server 2010 is joined with the
Domain Name System (DNS). DNS serves as the lookup agent for Exchange
Server 2010, AD, and most new Microsoft applications and services. DNS
translates common names into computer-recognizable IP addresses. For
example, the name www.cco.com translates into the IP address of 12.155.166.151. AD and Exchange Server 2010 require that at least one DNS server be made available so that name resolution properly occurs.
Given the dependency that
both Exchange Server 2010 and AD have on DNS, it is an extremely
important design element.
Reviewing DNS Namespace Considerations for Exchange Server
Given Exchange
Server 2010’s dependency on DNS, a common DNS namespace must be chosen
for the AD structure to reside in. In multiple tree domain models, this
could be composed of several DNS trees, but in small organization
environments, this normally means choosing a single DNS namespace for
the AD domain.
There is a great deal
of confusion between the DNS namespace in which AD resides and the email
DNS namespace in which mail is delivered. Although they are often the
same, in many cases there are differences between the two namespaces.
For example, CompanyABC’s AD structure is composed of a single domain
named abc.internal, and the email domain to which mail is delivered is companyabc.com.
The separate namespace, in this case, was created to reduce the
security vulnerability of maintaining the same DNS namespace both
internally and externally (published to the Internet).
For simplicity, CompanyABC could have chosen companyabc.com
as its AD namespace. This choice increases the simplicity of the
environment by making the AD logon user principal name (UPN) and the
email address the same. For example, the user Pete Handley is [email protected] for logon, and [email protected]
for email. This option is the choice for many organizations because the
need for user simplicity often trumps the higher security.
Optimally Locating Global Catalog Servers
Because all
Exchange Server directory lookups use AD, it is vital that the essential
AD global catalog information is made available to each Exchange server
in the organization. For many small offices with a single site, this
simply means that it is important to have a full global catalog server
available in the main site.
The global catalog is an
index of the AD database that contains a partial copy of its contents.
All objects within the AD tree are referenced within the global catalog,
which enables
users to search for objects located in other domains. Every attribute
of each object is not replicated to the global catalogs, only those
attributes that are commonly used in search operations, such as first
name and last name. Exchange Server 2010 uses the global catalog for the
email-based lookups of names, email addresses, and other mail-related
attributes.
Note
Exchange Server
2010 cannot make use of Windows Server 2008 Read Only Domain Controllers
(RODCs) or Read Only Global Catalog (ROGC) servers, so be sure to plan
for full GCs and DCs for Exchange Server.
Because full
global catalog replication can consume more bandwidth than standard
domain controller replication, it is important to design a site
structure to reflect the available WAN link capacity. If a sufficient
amount of capacity is available, a full global catalog server can be
deployed. If, however, capacity is limited, universal group membership
caching can be enabled to reduce the bandwidth load.
Understanding Multiple Forests Design Concepts Using Microsoft Forefront Identity Manager (FIM)
Forefront Identity
Manager (FIM) enables out-of-the-box replication of objects between two
separate AD forests. This concept becomes important for organizations
with multiple Exchange Server implementations that want a common Global
Address List for the company. Previous iterations of FIM required an
in-depth knowledge of scripting to be able to synchronize objects
between two forests. FIM, on the other hand, includes built-in scripts
that can establish replication between two Exchange Server 2010 AD
forests, making integration between forests easier.