Understanding Network Services and Active Directory Domain Controller Placement for Exchange Server 2013 (part 8)

Examining the Role of Domain Controllers in AD

Even before the existence of Active Directory, Exchange has relied on domain controllers to authenticate user accounts. With the advent of Active Directory, this has not changed. Exchange still relies on domain controllers to provide all authentication services. To provide optimal logon authentication response times, the proper placement of domain controllers is crucial.

Examining Domain Controller Authentication in Active Directory

To understand how Exchange manages security, an analysis of Active Directory authentication is required. This information aids in troubleshooting the environment, as well as in gaining a better understanding of Exchange Server 2013 as a whole.

Each object in Exchange, including all mailboxes, can have security directly applied for the purposes of limiting and controlling access to those resources. For example, a particular administrator might be granted access to control a certain set of Exchange servers, and users can be granted access to mailboxes. What makes Exchange particularly useful is that security rights can be assigned not only at the object level, but also at the attribute level. This enables granular administration, by allowing tasks such as a Telecom group being able to modify only the phone number field of a user, for example.

When a user logs on to a domain, the domain controller performs a lookup to ensure a match between the username and password. If a match is made, the client is then authenticated and given the rights to gain access to resources.

Because the domain controllers provide users with the permission to access the resources, it is important to provide local access to domain controllers for all Exchange servers. If a local domain controller became unavailable, for example, users would be unable to authenticate to their mailboxes in Exchange, effectively locking them out.

Determining Domain Controller Placement with Exchange Server 2013

Because Exchange relies on the security authentication performed by Active Directory domain controllers, the placement of these domain controllers becomes critical to the overall performance of your messaging environment. If a domain controller cannot be reached in a reasonable amount of time, access to messages and network resources is delayed.

At a minimum, at least one Active Directory domain controller must be within close proximity to any Exchange server to ensure speedy authentication for local users and mailboxes. Additional Active Directory domain controllers can be implemented to provide increased performance in heavily utilized sites or to provide redundancy in the event of a domain controller failure.

For organizations with a high concentration of Exchange servers and clients, a significant demand for directory services can negatively impact all aspects of network performance. The presence of other applications and services that require authentication, directory services, or directory replication can cause your Exchange performance to suffer. A current best practice to avoid these pitfalls is to create a dedicated Active Directory site, with dedicated domain controllers and global catalog servers. By segmenting a Service Delivery Location (SDL) into multiple Active Directory sites, you can separate the directory traffic generated by Exchange servers and Microsoft Outlook clients from other directory service traffic.

In addition, you can deploy more than one Active Directory domain controller in close proximity to users for user authentication. This enables the distribution of domain controller tasks and builds redundancy into the design. Because each Microsoft Windows Server 2012 domain controller is a multimaster, in the event of a failure of one domain controller, others are able to continue to function and allow uninterrupted authentication.

Defining the Global Catalog

The global catalog is an index of the Active Directory database that stores a full replica of all objects in the directory for its host domain, and a partial replica of all objects contained in the directory of every domain in the forest. In other words, a global catalog contains a replica of every object in Active Directory, but with a limited number of each object’s attributes.

Global catalog servers, often referred to as GCs, are Active Directory domain controllers that house a copy of the global catalog. A global catalog server performs two key roles:

• Provides universal group membership information to a domain controller when a logon process is initiated

• Enables finding directory information regardless of which domain in the forest contains the data

Access to a global catalog server is necessary for a user to authenticate to the domain. If a global catalog is not available when a user initiates a network logon process, the user is only able to log on to the local computer, and cannot access network resources.

With such an important role to play, it is a common practice to locate at least one global catalog server in each physical location, as it is referenced often by clients and by applications such as Exchange.

Understanding the Relationship Between Exchange Server 2013 and the AD Global Catalog

In the past, an Exchange server could continue to operate by itself with few dependencies on other system components. Because all components of the mail system were locally confined to the same server, downtime was an all-or-nothing prospect. The segregation of the directory into Active Directory has changed the playing field somewhat. In many cases, down-level clients no longer operate independently in the event of a global catalog server failure. Keep this in mind, especially when designing and deploying a domain controller and global catalog infrastructure.

Understanding Global Catalog Structure

The global catalog is an oft-misunderstood concept with Active Directory. In addition, design mistakes with global catalog placement can potentially cripple a network, so a full understanding of what the global catalog is and how it works is warranted.

As mentioned earlier, Active Directory was developed as a standards-based LDAP implementation, and the AD structure acts as an X.500 tree. Queries against the Active Directory must, therefore, have some method of traversing the directory tree to find objects. This means that queries that are sent to a domain controller in a subdomain need to be referred to other domain controllers in other domains in the forest. In large forests, this can significantly increase the time it takes to perform queries.

In Active Directory, the global catalog serves as a mechanism for improving query response time. The global catalog contains a partial set of all objects (users, computers, and other AD objects) in the entire AD forest. The most commonly searched attributes are stored and replicated in the global catalog (that is, first name, username, email address). By storing a read-only copy of objects from other domains locally, full tree searches across the entire forest are accomplished significantly faster. So, in a large forest, a server that holds a copy of the global catalog contains information replicated from all domains in the forest.

Using Best Practices for Global Catalog Placement

All users accessing Exchange resources should have fast access to a global catalog server. At least one global catalog server must be installed on each domain that contains an Exchange server; however, to achieve the best performance in larger organizations, additional global catalog servers should definitely be considered.

As a starting point, per site, there should be a 4:1 ratio of Exchange processor cores to global catalog server 32-bit processor cores. So, if you have four Exchange servers, each with four processors, you should have four processors running your global catalog servers. For global catalog servers with 64-bit processor cores, there should be an 8:1 ratio of Exchange processor cores to global catalog server 64-bit processor cores when there is sufficient memory in to cache the entire Active Directory database (DIT file). Of course, Exchange Server 2013 processor cores are always 64-bit.

Bear in mind, however, that increased global catalog server usage, very large Active Directory implementations, or the use of extremely large distribution lists might necessitate more global catalog servers.

Promoting a Domain Controller to a Global Catalog

Although any domain controller can easily be promoted to a global catalog server, the promotion can have a significant impact on network operations and performance while the topology is updated and the copy of the catalog is passed to the server.

The procedure to promote a domain controller to a global catalog server is as follows:

1. Open the Active Directory Sites and Services tool.

2. In the console tree, double-click Sites, double-click the name of the site, and then double-click Servers.

3. Double-click the target domain controller.

4. In the details pane, right-click NTDS Settings, and then click Properties.

5. On the General tab, click to select the Global Catalog check box, as shown in Figure 5.

Figure 5. Making a domain controller a global catalog server.

6. Click OK to finalize the operation.