Dedicated Active Directory Sites for Exchange

Published Aug 28 2006 03:57 PM 3,147 Views

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.

Additional Reading Material

XADM: Exchange 2000 May Experience Performance Problems When PDC Emulator Is Used for DSAccess

Exchange Server 2003 and Active Directory

Exchange 2000 Server and Active Directory

XADM: Exchange 2000 May Experience Performance Problems When PDC Emulator Is Used for DSAccess

XGEN: Optimizing Windows 2000 Active Directory Servers with Six or Eight Processors to Run with Exchange 2000

Within few days, I will talk more about measuring the AD performance.

- Paul Flaherty

Not applicable
Great post, how about a follow up with some best practices for setting up the application specific sites?

Answering questions like:

Should the DCs be limited to only serving Exchange or available to other applications as a last resort?

Should Exchange servers have sequential IPs or should the site include the individual IPs of each server/

Which FSMO roles (if any, GC obviously) should these DCs hold?

Not applicable
Great post and Excellent timing!

Exchange 2007 follow up topics:

What DSAccess/DSProxy exist in Exchange 2007?

What are the impacts and mitigations when upgrading to an Exchange 2003 with a dedicated AD site to Exchange 2007's (AD based routing)?

Not applicable

Yes Exchange 2007 will use the AD Site topology for routing purposes (basically to determine least cost route and where Hub Transport servers are in relation to that least cost route, so that we can either perform a direct connection to the destination server or get it as close as possible, while bifurcating the message at the last possible moment).

Also remember that you need a Hub Transport role in every AD Site where you deploy a mailbox server.    

If you have a dedicated site for Exchange today, then chances are you will probably keep it for Exchange 2007 for the same directory isolation boundary.  

As far as routing is concerned in that scenario, well the dedicated AD Site will be used as a point of egress for mail leaving the AD site and as a point of ingress for mail entering the AD site.  The default configuration of the routing engine in Exchange 2007 will mean that we will try and use direct relay where possible after we bifurcate the message (if multiple recipients are on the same message, split the message into separate messages for the recipients when the least cost route for the recipients diverge) which means we will attempt to send directly to the destination server instead of passing the messages through each Hub Transport server in the least cost route.

Also, you may want to take a look at this:

Hope this helps.

Not applicable

In the case of dedicating an AD Site for Exchange, you are typically dedicating it to that sole application.  Adding in additional applications that utilize the directory could potentialy increase the lookup and response times and impact Exchange (which is what you want to avoid).

IP scheme doesn't matter.  Remember the AD Site topology is a logical representation of the physical.  Creating a new AD site doesn't require you to change your IP subnet architecture.  You can create a new AD Site and specify each server you want to reside in that site by specifying the server's IP address with a 32-bit subnet mask as the AD Site subnet.

They don't need to hold any FSMO roles.

Also, this article may help -

Not applicable

DSProxy in Exchange 2007 has the same functionality as Exchange 2003 SP2.  See for more information.

Not applicable
Another way to do this w/o modifying your AD topology is to raise the SRV record cost (therefor deprioritizing them) on specific GCs, and then specifying them as GC servers under DS Access?
Why try to be smarter than AD and the auto-selection process? Politics sometimes demand that technology work in the non-default manner such as when application specific AD sites are not avaialble as an option.
Not applicable
You are scaring me. If I have ten domains I need 20 new GCs into dedicated Exchange Site. Two is needed because of failover. Honestly, is this what you are thinking ? :-o

Okay, DSAccess’ Incarnation list keeps only ten servers, so more than 10 is not useful.

And "" says: "GC that is one of the GCs that the Exchange Server is currently using - 4 points".
If I have six Exchange servers in most of cases DSAccess choose the wrong GC for the users.

As "Marc C" says in his comment (other blog) this problem is million years old. For us this really seems that you are not discussing with Office team for fixing this :-|

The scenarios when this happens are:
- Modify the DL from other domain than your mail enabled account is.
- Delegate permissions for someone else into your mailbox.
- Delegate permissions on the shared mailbox.
All of these are very minor tasks and you don't do these everyday. It is a little frustrating to use 20 DC for these special tasks only (cause all other Outlook tasks are not related of the GC). So in these cases Outlook can use own prefer list of GCs for these special tasks.

We can keep isolated site for Exchange, but getting one/two DCs from other domains is not the answer what you like to hear.

Not applicable
After preparing your Active Directory you're ready to install Microsoft Exchange Server 2007 to bring
Version history
Last update:
‎Jul 01 2019 03:17 PM
Updated by: