Installing and Configuring the Basics of Exchange Server 2013 for a Brand-New Environment (part 3)

6. Understanding Flexible Single Master Operations Roles

Active Directory uses a multimaster replication scheme for replicating directory information between domain controllers; however, certain domain and enterprisewide operations are not well suited for a multimaster model. Some services are better suited to a single master operation to prevent the introduction of conflicts while an Operations Master is offline. These services are referred to as Operations Master or Flexible Single Master Operations (FSMO) roles.

FSMO roles can be either forestwide or domainwide. The forestwide roles consist of the schema master and the domain naming master. The domainwide roles consist of the Relative ID (RID) master, the Primary Domain Controller (PDC) emulator, and the infrastructure master. A brief description of each is as follows:

• Schema master—Maintains all modifications to the schema throughout the Active Directory forest, as no other domain controller is allowed to write to the schema. The schema determines what types of objects are permitted in the forest and the attributes of those objects.

• Domain naming master—Maintains a list of the names of all domains in the forest and is required to add any new domains (or to remove existing ones).

• RID master—Allocates security RIDs to domain controllers to assign to new AD security users, groups, or computer objects. RIDs are the part of the security identifier (SID) that identifies an account or group within a domain. The RID master also manages objects moving between domains.

• PDC emulator—Processes all password changes in the domain. If a user logon attempt fails due to a bad password, the request is forwarded to the PDC emulator to check the password against the most recent one. This allows a user to log on immediately after a password change instead of having to wait for that change to replicate throughout the Active Directory.

• Infrastructure master—Maintains security identifiers, globally unique identifiers (GUIDs), and DNS for objects referenced across domains. This role is also responsible for ensuring that cross-domain group-to-user references are correctly maintained.

When designing the FSMO role placement of an Active Directory environment, the following best practices should be considered:

• If a domain has only one domain controller, that domain controller holds all the domain roles. However, this configuration is not recommended (even for smaller organizations), as it creates a single point of failure.

• The schema master and domain naming master should be placed on the same domain controller in the root or placeholder domain. This server can (and should) also be configured as a global catalog server.

• Place the RID master and PDC emulator roles on the same domain controller. If the load on this server justifies separating the roles, place them on domain controllers in the same domain and AD site and ensure the two domain controllers are direct replication partners of each other.

• As a general rule, the infrastructure master should be deployed on a domain controller that is not also a global catalog server. This domain controller should have a direct connection to a GC server, preferably in the same Active Directory site. Global catalog servers hold a partial replica of every object in the forest and the infrastructure master, when placed on a global catalog server, will never update anything as it does not contain any references to objects that it does not hold. There are two exceptions to this rule:

• Single domain forest—In a forest with a single AD domain, there are no phantoms and the infrastructure master has no work to do. In this case, the infrastructure master can be placed on any domain, including those that are also global catalog servers.

• Multidomain forests where every domain controller is a global catalog server—When every domain controller in a domain that is part of a multidomain forest is configured as a global catalog server, there are no phantoms or work for the infrastructure master to do. The infrastructure master can be placed on any domain controller in the domain.

7. Understanding How DNS and AD Namespace Are Used in Exchange Server 2013

The first step in the actual design of the AD structure is the decision on a common DNS namespace that AD will occupy. AD revolves around (and is inseparable from) DNS, and this decision is one of the most important ones to make. The namespace chosen can be as straightforward as companyabc.com, for example, or it can be more complex. Multiple factors must be considered, however, before this decision can be made. Is it better to register an AD namespace on the Internet and potentially expose it to intruders, or is it better to choose an unregistered, internal namespace? Is it necessary to tie in multiple namespaces into the same forest? These and other questions must be answered before the design process can proceed.

8. Impact Forests Have on an Exchange Server 2013 Design

An AD forest and an Exchange Server organization are tightly integrated. Exchange Server relies on AD as its directory repository for mailboxes, mail-enabled objects, Exchange servers, and much more. An AD forest can only host a single Exchange organization, and an Exchange organization can only span one AD forest.

It is recommended that a single AD forest should be utilized to minimize complexity and administration when designing and implementing a company’s Exchange Server implementation. However, there will be times when a single AD forest will not meet the company’s business, security, or political requirements.

If multiple AD forests are necessary to satisfy the company’s requirements, it must be decided on which forest the Exchange organization will be hosted. It is possible to have Exchange Server reside in a single forest, a dedicated resource forest, or to implement multiple Exchange organizations in multiple forests.

9. The Role of a Domain in Exchange Server 2013

After the AD forest structure has been laid out, the domain structure can be contemplated. Unlike the forest structure, an Exchange Server 2013 organization can span multiple domains within the forest if needed. Therefore, a user mailbox, Exchange server, or other Exchange object can reside in any domain within the forest where Exchange Server 2013 has been deployed. A company can plan its domain model structure (single domain model or multiple domain model) based on its business and security requirements without a direct negative impact to the Exchange Server 2013 design.

Although a single domain model is often considered due to its simplicity, some organizations prefer the Placeholder Domain. 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 1.

Figure 1. The placeholder domain model.

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. A downside to this model, however, is that it requires a separate set of domain controllers, which increases the infrastructure costs of the environment. Smaller organizations may have a difficult time justifying the extra infrastructure costs to provide the increased security, but whenever the budget allows, this model should be considered.