- Planning for Exchange Server 2013
- Understanding AD Design Concepts for Exchange Server 2013
- Determining Exchange Server 2013 Placement
- Configuring Exchange Server 2013 for Maximum Performance and Reliability
- Securing and Maintaining an Exchange Server 2013 Implementation
- Summary
- Best Practices
This chapter is from the book
This chapter is from the book
This chapter is from the book
Understanding AD Design Concepts for Exchange Server 2013
After all objectives, dependencies, and requirements have been mapped out, the process of designing the Exchange Server 2013 environment can begin. Decisions should be made in the following key areas:
- AD DS design
- Exchange server placement
- Global catalog placement
- Client access methods
Understanding the AD DS Forest
Because Exchange Server 2013 relies on the Windows Server 2008 AD DS for its directory, it is therefore important to include AD DS in the design plans. In many situations and AD implementations, whether based on Windows Server 2003, Windows Server 2008, or Windows Server 2012, AD DS already exists in the organization. In these cases, it is necessary only to plan for the inclusion of Exchange Server into the existing forest.
If an AD DS structure is not already in place, a new AD DS forest must be established for Exchange to be installed into. Designing the AD DS 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 DS before beginning an Exchange Server 2013 design.
In short, a single instance of AD DS consists of a single AD DS forest. A forest is composed of AD DS trees, which are contiguous domain namespaces in the forest. Each tree is composed of one or more domains, as illustrated in Figure 2.1.
)
Figure 2.1. Multitree AD DS forest design.
Certain cases exist for using more than one AD DS forest in an organization:
- Political limitations—Some organizations have specific political reasons that force the creation of multiple AD DS 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 DS 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 if they know what they are doing. Although these types of vulnerabilities are not common and are difficult to do, highly security-conscious organizations should implement separate AD DS forests or organizational units with delegated rights.
- Application functionality—A single AD DS 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, though this particular scenario is particularly discouraged.
- Exchange-specific functionality (resource forest)—In certain circumstances, it might be necessary to install Exchange Server 2013 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 DS forests that creates a third forest specifically for Exchange Server, called a resource forest, and uses cross-forest trusts to assign mailbox permissions.
The simplest designs often work the best. The same principle applies to AD DS 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 DS 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 2013 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.2.
)
Figure 2.2. The placeholder domain model.
The placeholder domain structure segregates 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. This is a model that was once commonly deployed by organizations before it became apparent that the domain is not an effective security boundary.
Reviewing AD DS Infrastructure Components
Several key components of AD must be installed within an organization to ensure proper Exchange Server 2013 and AD DS 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 2013 Design
In addition to being tightly integrated with AD DS, Exchange Server 2013 is joined with the Domain Name System (DNS). DNS serves as the lookup agent for Exchange Server 2013, 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 DS and Exchange Server 2013 require that at least one DNS server be made available so that name resolution properly occurs.
Given the dependency that both Exchange Server 2013 and AD DS have on DNS, it is an extremely important design element.
Reviewing DNS Namespace Considerations for Exchange Server
Given Exchange Server 2013’s dependency on DNS, a common DNS namespace must be chosen for the AD DS 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 DS domain.
There is a great deal of confusion between the DNS namespace in which AD DS resides and the email DNS namespace in which mail is delivered. Although they are often the same, there is no reason that the two namespaces have to be the same. When Exchange Server is first installed, the AD domain is chosen as the default SMTP domain, but that can be changed. For example, CompanyABC’s AD DS 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 because someone believed that it reduced the security vulnerability of maintaining the same DNS namespace both internally and externally (published to the Internet).
Likewise, there is no necessary relationship between the Active Directory user principal name (UPN) that can be used for user logon and the SMTP email address, but using the same for both makes it easier for users.
For simplicity, CompanyABC could have chosen companyabc.com as its AD DS namespace. This choice increases the simplicity of the environment by making the AD DS logon UPN and the email address the same. For example, the user Pete Handley is pete@companyabc.com for logon and pete@companyabc.com 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 where there are Exchange servers.
The global catalog is an index of the AD DS database that contains a partial copy of its contents. All objects within the AD DS tree are referenced within the global catalog, which enables users to search for objects located in other domains. Not every attribute of each object is replicated to the global catalogs, only those attributes that are commonly used in search operations, such as first name and last name. Exchange Server 2013 uses the global catalog for the email-based lookups of names, email addresses, and other mail-related attributes.
Because full global catalog replication adds bandwidth usage to the 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.