Exchange 2003 servers can benefit from an Active Directory design that utilizes site architecture to isolate Exchange. This is best achieved through creating a dedicated Active Directory site which contains both Exchange 2003 servers and Global Catalog servers that are dedicated to the Exchange DSAccess process. The potential benefits of this architecture are as follows:
- Reduction of Global Catalog overload potential through isolating Exchange messaging traffic and processes from the remainder of the environment by using dedicated Global Catalogs.
- Increased performance for Exchange LDAP queries through Global Catalogs that are dedicated to the Exchange DSAccess process. NB: This assumes that you have the right number of GC processors to Exchange processors and a well connected network.
- Easier Management and monitoring of the Exchange environment due to segregating out of non-Exchange processes. NB: However, this segregation will increase the number total number of domain controllers in your environment
- Increased performance for non-Exchange LDAP and directory services processes due to Exchange process segregation. NB: This assumes that you have enough GC’s to service non-Exchange traffic
Excessive LDAP Read and Search Times can have a negative impact of the ability to service messaging requests. This could include:
- Impact to mail routing (for mail bound internally and externally)
- Impact to Client Ambiguous Name Resolution requests (i.e. address lookups DL expansions etc)
- Impact other functional processes, login authentication for resources (i.e. calendar and PFs) DL access Group Membership
As far as the Active Directory is concerned, Exchange is just an application. While it may be convenient for applications like Exchange to have dedicated sites, it adds complexity to AD. This may be the best approach from the application's perspective, particularly if AD isn't managed correctly or isn't being actively monitored for performance and scaled accordingly. From the AD service owner's perspective, it has dozens if not hundreds of applications to service. AD will strive to provide acceptable levels of service to all clients/apps without extra sites (Extra sites are defined as app-specific ones instead of those based on network topology). What level of performance is deemed acceptable for the AD and the Application (In this case Exchange)? It's entirely up to the application. The service owners need to understand this, monitor their systems closely, and ensure they have the right number of DCs available to meet application requirements.
There is also a risk angle. Even if AD can provide acceptable performance to applications during normal conditions, what happens when an applications starts to perform erratically? If steps are not in place to immediately isolate and repair this behavior, one bad application will begin to impact the others. Dividing AD into separate app-specific sites can help somewhat, but it's not a magic bullet. If another application decides to write millions of objects to the directory in a short period of time, the replication load would span sites and impact the "dedicated" Exchange DCs.
Application owners will generally prefer dedicated domain controllers over shared ones because it reduces the number of external influences on their application. This is not necessarily the best approach for the directory system as a whole because the added complexity is expensive and more difficult to manage. If an organization isn't comfortable with the risk of directory-enabled applications affecting each other, implementing dedicated sites is one way to reduce their risk. Exchange is a very important directory-enabled app and often warrants this kind of protection. That being said, the organization should evaluate their applications and rate each one on criticality, predictability, and supportability. There's nothing wrong with using those same Exchange DCs for other critical, predictable, supportable applications instead of building yet another set of sites.
If you consider Exchange and Outlook as a service (Email), then the change in the DSProxy algorithm introduced in Exchange Server 2003 Service Pack 2 (SP2) adds some additional concerns. If you have a multi domain forest, which has Exchange (and maybe some users) in one domain and users in another, then you may need to add GCs from the users domain into the Active Directory Site where the Exchange servers reside. Of course, this also increases the number of servers required for a dedicated Exchange Site.