A comment I received on a previous post on sites and subnets in Active Directory was "what benefit(s) does a dedicated Exchange site provide?". There's a couple things to consider here with the advent of Exchange 2007. The first is the great degree of dependency Exchange has on Active Directory data for everything it does. The second, applicable to Exchange 2007 deployments is that Exchange now uses the Active Directory site topology to route email. I'm not familiar enough with this scenario yet to speak to it, but I will speak to the need for fast and reliable global catalog access for Exchange servers.
With Exchange 2000 and 2003, the vast majority of the configuration data for Exchange is stored in Active Directory in the Exchange services container in the configuration partition. All of the configuration data for recipients is stored on top of the objects representing them in Active directory – users for mailboxes, contacts, distribution groups, public folders, etc. More specifically when Exchange needs access to this data, it goes to a global catalog server to get it as a global catalog holds the relevant data for every single recipient in the forest. The configuration partition information can be read from any DC in a forest due to the replication scope of the partition. In a busy Exchange deployment, Exchange places an disproportionate load on the global catalogs it uses as compared to clients. Every single message that has to be routed requires a look up against a global catalog, distribution list expansions, address book builds, etc.
When the Active Directory traffic generated by Exchange isn't segmented off of that generated from end users, workstations, and other applications there tends to be a performance hit seen by both parties. If the shared domain controllers are too busy with Exchange, complaints about logon times can be seen. Conversely, if the shared domain controllers are too busy with logon traffic and servicing other applications, Exchange will see a hit must notably in message routing. These scenarios of course apply to larger Exchange deployments – a small operation is unlikely to run into this.
The solution to this problem is to deploy a dedicated Active Directory site for Exchange. If you have multiple datacenters with highly concentrated Exchange deployments in them, the solution might actually be multiple Exchange sites enterprise-wide. Place a couple of global catalogs in these sites which are geared towards very high read performance – 64 bit deployments with as much memory as possible to hold a large amount (or all of) the DIT in memory will see a huge performance gain.
This article from TechNet explains a handful of performance counters which should be monitored to see if Active Directory may be the root of Exchange performance issues.
This article from Microsoft IT Showcase explains exactly how to go about configuring a dedicated Exchange site. Note that Microsoft IT deployed a series of /32 subnet objects to create their Exchange site. It is also possible to provision dedicated Exchange subnet(s) in your datacenter(s) and associate those with an Exchange site. I've taken both paths and generally it tends to depend more on whether the network guys at the shop are willing to light up a dedicated site or not.