If you would like to read the other parts in this article series please go to:
- Solutions for Virtualizing Domain Controllers (Part 1)
- Solutions for Virtualizing Domain Controllers (Part 2)
- Solutions for Virtualizing Domain Controllers (Part 3)
- Solutions for Virtualizing Domain Controllers (Part 5)
- Solutions for Virtualizing Domain Controllers (Part 6)
- Solutions for Virtualizing Domain Controllers (Part 7)
Introduction
In my previous article, I discussed several different options for distributing domain controllers among host servers in a virtual environment. One of the issues that I did not cover in that article was the placement of global catalog servers. In this article, I want to focus my attention on how global catalog server placement works in a virtual environment.
What is a Global Catalog Server?
Most of you who are reading this article are probably already familiar with the concept of a global catalog server. For the benefit of those who may be new to the Active Directory, I want to take a moment and explain what a global catalog server is, and what it does. If you are already familiar with global catalog servers, then feel free to skip to the next section.
I could easily write an entire series of articles on the role of global catalog servers, but in the interest of not losing focus, I will try to keep this simple. The Active Directory consists of one or more domains. Each of these domains is made up of one or more domain controllers. Each domain controller contains a domain directory partition. The domain directory partition contains a copy of all of the Active Directory objects (user accounts, computers, groups, etc.) that exist within the domain.
Because the Active Directory replication process keeps each of the domain controllers within a domain synchronized, each domain controller contains a copy of every object within the domain that services. Hence, a domain controller is able to service requests for its domain.
Larger networks often use Active Directory forests consisting of multiple domains. In these types of environments, global catalog servers provide the ability to locate objects within any domain in the forest, but without having to know which domain the object exists in. That’s because domain controllers which have been designated to act as global catalog servers contain read-only replica of every domain directory partition in the forest. These partitions exist in addition to the domain directory partition for the domain that the global catalog server is a member of.
Single Domain Forests
As you may recall, in the previous article I referred to the diagram shown in Figure A. This diagram shows a single domain forest with domain controllers spread across both physical and virtual machines.
Figure A: Global catalog server placement becomes a moot point in a single domain forest
In a network such as the one illustrated above, global catalog server placement is a nonissue. The reason for this is that a single domain forest there is only one domain directory partition. Every single domain controller in the forest contains a copy of the one and only domain directory partition. As such, every domain controller should be configured to act as a global catalog server. Doing so would not be advisable in a multi-domain forest, but you can get away with configuring every domain controller in a single domain forest to act as a global catalog server because doing so does not increase CPU or disk space usage, nor does it increase replication traffic.
When it comes to multi-domain forests, global catalog server placement must be considered more carefully. Before I begin discussing global catalog server placement, it is important for you to realize that although the global catalog server role is applied at the domain controller level, global catalog searches are actually a forest level operation.
With that in mind, Microsoft recommends that each Active Directory site be provided with its own global catalog server. This recommendation comes with several different caveats though.
One of the primary considerations that you will have to take into account is application dependency upon global catalog servers. A perfect example of this dependency is Exchange Server. Microsoft’s best practices for Exchange Server dictate that you should have at least one global catalog server in every Active Directory site in which a mailbox server exists. That particular recommendation isn’t exactly surprising because it adheres to Microsoft’s general recommendation for global catalog server placement. However, there are some situations in which multiple global catalog servers may be required within a site. For example, organizations with large Exchange Server deployments will typically require multiple global catalog servers. Microsoft recommends a 4 to 1 ratio of mailbox servers to global catalog servers within a site. Therefore, if an Active Directory site contains eight mailbox servers, then you will need at least two global catalog servers in the site.
The number of required global catalog servers isn’t the only consideration that you must take into account when it comes to your applications though. One often overlooked Exchange Server requirement is that the global catalog servers cannot reside on read-only domain controllers. While Microsoft does support (and in some cases even recommends) designating read-only domain controllers to act as global catalog servers, Exchange Server is not compatible with read-only domain controllers. Therefore, the limitation doesn’t exist with the domain controllers themselves, but rather with the application.
In some cases, you may find that it is impractical to place a global catalog server within an Active Directory site. This is particularly true for remote sites that are separated from the Main office by a low speed connection. In such situations, the Active Directory replication traffic required for maintaining the Global Catalog server may saturate your WAN connection.
Placing a global catalog server within an Active Directory site may also be impractical if there are fewer than 100 users in the site. Although you can provide a global catalog server to such sites, doing so is widely considered to be overkill unless an application dependency exists, or unless the site primarily services roaming users (roaming users must contact a global catalog server at logon).
As you can see, there are some situations in which placing a global catalog server within an Active Directory site may not be the best course of action. Even so, users within that site must still be able to resolve Active Directory requests. Fortunately, Microsoft does provide us with an alternative method that can be used in these situations.
As I’m sure you know, every Active Directory site requires at least one domain controller. Rather than designating the domain controller to be a global catalog server, you can enable universal group membership caching. This allows the domain controller in the site to cache global group and universal group SIDS that are acquired from a global catalog server. Although universal group membership caching greatly reduces the dependency on global catalog servers, it is important to make sure that sites using universal group membership caching are never more than one replication hop away from a global catalog server.
Conclusion
In this article, I have discussed some of Microsoft’s recommendations regarding global catalog server placement. In the next part of this article series, I will begin examining multi-domain architectures as they apply to virtual data centers. As I do, I will also be discussing global catalog server placement in such environments.
If you would like to be notified of when Brien Posey releases the next part in this article series please sign up to our VirtualizationAdmin.com Real Time Article Update newsletter.
If you would like to read the other parts in this article series please go to:
- Solutions for Virtualizing Domain Controllers (Part 1)
- Solutions for Virtualizing Domain Controllers (Part 2)
- Solutions for Virtualizing Domain Controllers (Part 3)
- Solutions for Virtualizing Domain Controllers (Part 5)
- Solutions for Virtualizing Domain Controllers (Part 6)
- Solutions for Virtualizing Domain Controllers (Part 7)
