Installing Exchange Server 2010 : Understanding the Active Directory Requirements for Exchange Server 2010

If AD is already deployed, it is important that the team designing the Exchange Server infrastructure have a solid understanding of the existing AD environment. Organizations with an AD infrastructure already in place need to evaluate how Exchange Server can fit into their environment. If AD has not been deployed, the organization or team designing Exchange Server needs to plan their implementation with a thought as to what their messaging infrastructure will look like.

This section is designed to give a basic understanding of the AD infrastructure required to support an Exchange Server 2010 implementation. Many facets are involved when planning a production AD infrastructure—forest model, domain model, group policies, and delegation of administration to name a few, and the information needed to design an AD infrastructure from end to end is beyond the scope of this book.

Some of the AD factors that should be considered when deploying Exchange Server 2010 include the following:

• Global Catalog Server Placement

• AD Sites and Services

• Forest and Domain Functional Levels

• Flexible Single Master Operations Role Placement

• Permissions Needed to Install Exchange

• Bandwidth and Latency in the Network

Global Catalog Server Placement

As was the case in Exchange 2000 Server through Exchange Server 2007, Exchange Server 2010 requires a global catalog infrastructure to function. The global catalog maintains an index of the Active Directory database for objects within its domain. Additionally, it stores partial copies of data for all other domains within a forest.

Just as important, Exchange Server relies on global catalog servers to resolve email addresses for users within the organization. Failure to contact a global catalog server causes emails to bounce, as the recipient’s name cannot be resolved.

Active Directory Sites and Services

In Exchange Server 2003 and earlier, Exchange Server utilized dedicated routing topology for transporting messages throughout the organization. Beginning with Exchange Server 2007, Microsoft redesigned the product to be a “site-aware” application. This continues in Exchange Server 2010.

Site-aware applications are able to determine what site they (and other servers) belong to by querying Active Directory. The site attribute of all Exchange server objects is maintained by the Microsoft Exchange Active Directory Topology Service. Additionally, Exchange Server 2010 servers utilize site membership to identify which Domain Controllers and Global Catalog servers should be utilized to process Active Directory queries.

The Exchange Server 2010 servers utilize Active Directory site membership as follows:

Hub Transport Servers— Gather information from Active Directory to determine mail routing inside the organization. When a message hits the Microsoft Exchange Transport service, the Hub Transport server resolves the recipient’s information and queries Active Directory to match an email address to the recipient’s account. The result of this query includes the fully qualified domain name (FQDN) of the user’s mailbox server.

From the FQDN, the AD site of the recipient’s Mailbox server is determined and, if the Mailbox server is in the same site as the Hub Transport server, the message is delivered. If the Mailbox server is in another site, the message is relayed to a Hub Transport server in that site, and the message is then delivered to the user’s mailbox server.

Client Access Servers— When a client access server receives a connection request from a user, it contacts AD to determine which mailbox server houses the user’s mailbox and which site that server belongs to. If the mailbox server is in a different site, the connection is redirected to a client access server in the same site as the mailbox server.

Mailbox Servers— Query Active Directory to determine which Hub Transport servers are located in their site. Messages are submitted to local Hub Transport servers for routing and transport.

Unified Messaging Servers— Utilize Active Directory site membership information to determine what Hub Transport servers are located in the same site as the UM server. Messages for routing and transport are delivered to a Hub Transport server in the same site as the UM server.

Forest and Domain Functional Levels

With each new edition of the Windows Server and Exchange Server operating systems, new functionalities are introduced. Some of these enhancements require that the Active Directory infrastructure be upgraded before you can take advantage of the new capabilities. At times, these capabilities cannot be implemented until all domain controllers in an environment have been upgraded to the same level.

To support this, Active Directory has Forest and Domain functional levels that determine what enhancements are enabled or disabled. By raising the functional level of an environment, new functionalities are enabled. By maintaining an older functional level, interoperability with older domain controllers is supported.

Forest Functional Levels

Windows Server 2003 supports three forest functional levels:

• Windows 2000 Native— Required while any Windows Server 2000 domain controllers remain in your forest. Supports domain controllers running Windows NT 4.0, Windows 2000 server, and Windows Server 2003.

• Windows Server 2003 Interim— A special functional level only implemented during NT 4.0 to Windows 2003 upgrades.

• Windows Server 2003— All DCs in the forest must be running Windows Server 2003, and all domains in the forest must be at the Windows 2003 Domain functional level before you can raise your forest functional level to Windows Server 2003.

Windows Server 2008 supports three forest functional levels:

• Windows 2000 Native— Supports Windows 2000, Windows Server 2003, and Windows Server 2008 domain controllers.

• Windows Server 2003— Allows for a mix of Windows Server 2003 and Windows Server 2008 functional level domains.

• Windows Server 2008— Ensures all domain controllers in the forest are running Windows Server 2008 and all domains have been raised to the Windows Server 2008 domain functional level.

Domain Functional Levels

Windows Server 2003 supports four domain functional levels:

• Windows 2000 Mixed— Allows Windows Server 2003 domain controllers to interoperate with other domain controllers running Windows Server 2003, Windows 2000 Server, and Windows NT 4.0.

• Windows 2000 Native— Allows domain controllers running Windows Server 2003 to interact with domain controllers running either Windows Server 2003 or Windows 2000 Server.

• Windows Server 2003 Interim— Supports only domain controllers running Windows Server 2003 and Windows NT 4.0.

• Windows Server 2003— Supports only Windows Server 2003 domain controllers.

Windows Server 2008 supports three domain functional levels:

• Windows 2000 Native— Allows domain controllers running Windows Server 2008 to interact with domain controllers running either Windows Server 2008, Windows Server 2003, or Windows 2000 Server.

• Windows Server 2003— Supports an environment comprised of a mixture of Windows Server 2003 and Windows Server 2008 domain controllers.

• Windows Server 2008— Only available after all domain controllers in a domain are running Windows Server 2008.

Understanding Flexible Single Master Operations Roles

Active Directory uses a multimaster replication scheme for replicating directory information between domain controllers; however, certain domain and enterprise wide 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 in immediately after a password change instead of having to wait for that change to replicate throughout the active directory.

• Infrastructure Master— Maintains security 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 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:

  1. 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.

  2. 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.

Understanding How DNS and AD Namespace Are Used in Exchange Server 2010

The first step in the actual design of the AD structure is the decision on a common domain name system (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.

Impact Forests Have on an Exchange Server 2010 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 an Exchange Server reside in a single forest, a dedicated resource forest, or to implement multiple Exchange organizations in multiple forests.

The Role of a Domain in Exchange Server 2010

After the AD forest structure has been laid out, the domain structure can be contemplated. Unlike the forest structure, an Exchange Server 2010 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 2010 has been deployed. A company can plan its domain model structure (single domain model or multiple domain model) based on their business and security requirements without a direct negative impact to the Exchange Server 2010 design.

While a single domain model is often considered due to its simplicity, most organizations prefer 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 1.

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. 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 definitely be considered.

Planning a Proper Sites and Services Architecture

As stated earlier, one of the major features of Exchange Server 2007 and Exchange Server 2010 is the ability to natively utilize Active Directory Sites and Services for routing mail, rather than having to implement and maintain an independent routing topology using connectors. To take advantage of this capability, you must first remove all pre-Exchange Server 2007 servers from your environment.

If Exchange Server 2010 will be installed into an existing Exchange Server 2003 organization, the administrators must configure routing group connectors to ensure that the Exchange Server 2010 servers are communicating to legacy servers.

Administrators should be aware of the best practices for designing a proper Sites and Services architecture to support Exchange Server 2010. From a high-level perspective, within AD it is necessary for administrators to create sites, allocate subnets to sites, and then create site links between sites for communication to occur. Similar to Exchange 2000 and 2003, it is possible to set up redundant links between sites and allocate costs to control communication priorities.

Active Directory Sites

The basic unit of AD replication is known as the site. Not to be confused with physical sites or Exchange Server 5.5 sites, the AD site is simply a group of domain controllers connected by high-speed network connections. Each site is established to more effectively replicate directory information across the network. In a nutshell, domain controllers within a single site will, by default, replicate more often than those that exist in other sites. The concept of the site constitutes the centerpiece of replication design in AD.

Associating Subnets with Sites

In most cases, a separate instance of a site in AD physically resides on a separate subnet from other sites. This idea stems from the concept that the site topology most often mimics, or should mimic, the physical network infrastructure of an environment.

In AD, sites are associated with their respective subnets to allow for the intelligent assignment of users to their respective domain controllers. For example, consider the design shown in Figure 2.

Figure 2. Sample Exchange Server and Client site assignment.

In this example, Server-EX01 is a physical member of the 192.168.115.0/24 subnet. Server-EX02 and Client01 are both members of the 192.168.116.0/24 subnet. Based on the subnets, Server-EX01 will automatically be assigned to the domain controller Server-DC01 in SITE01 and Server-EX02 and Client01 will be assigned to the domain controller Server-DC02 in SITE02.

Using Site Links

By default, the creation of two sites in AD does not automatically create a connection linking the two sites. This type of functionality must be manually implemented by the creation of a “site link.”

A site link is essentially a connection that joins together two sites and allows for replication traffic to flow from one site to another. Multiple site links can be set up and should normally follow the wide area network (WAN) lines of your organization. Multiple site links also assure redundancy so that if one link goes down, replication traffic has an alternate path.

Site link replication schedules can be modified to fit the requirements of your organization. If, for example, the WAN link is saturated during the day, a schedule can be established to replicate information at night. This functionality allows you to easily adjust site links to the needs of any WAN design.

Exchange Server 2010 and Site Membership

After the AD site topology has been created, including adding the appropriate subnets to sites and creating site links between sites, an administrator can now take Exchange Server placement into consideration.

Similar to AD domain controllers, Exchange Server 2010 servers will be associated with sites in AD based on their IP address and subnet mask. As stated earlier, there should be at least one domain controller/global catalog server residing in each site that an Exchange Server 2010 server will be in.

Establishing a Proper Global Catalog Placement Strategy

Another area of importance is the design and placement of global catalog servers within the environment. The importance of the global catalog server cannot be overstated. The global catalog is used for the address list that users see when they are addressing a message and by Exchange servers every time a message is delivered. If a global catalog server is not available, the recipient’s address will not resolve when users address a message, and the message cannot be delivered.

There should be at least one global catalog server in every AD site that contains an Exchange Server 2010 server. The recommendation from Microsoft is as follows:

If Active Directory is running on a 32-bit system, the recommendation is 4:1—for every four processor cores in your mailbox servers, you should have one processor core in a global catalog server. For example, if you have 2 mailbox servers, each with dual quad-core processors, that is 16 processor cores. You should have at least 4 processor cores worth of global catalog computing, so 1 quad core server, or 2 dual core servers should do the trick.

If Active Directory is running on a 64-bit system, the recommended ratio is 1:8. However, you must have enough memory installed on the server to cache the entire Active Directory database in memory. To confirm the size of your Active Directory database, look at the size of the %WINDIR%\NTDS\NTDS.DIT file.

For optimization, plan on having a global catalog server close to the clients to provide efficient address list access. Making all domain controller servers global catalog servers is recommended for an organization that has a single AD domain model and a single site. Otherwise, for multidomain models, all domain controllers can be configured as global catalog servers except for the domain controller hosting the Infrastructure Master FSMO role.