Manage Learn to apply best practices and optimize your operations.

How DSAccess service improves Exchange Server 2007 reliability

On a smaller network, DSAccess service will work with a couple domain controllers and a single global catalog server. On a larger network, however, DSAccess service can choose up to 10 domain controllers and 10 global catalog servers. What are the benefits of connecting Exchange 2007 to so many Active Directory servers? Find out here.

On my small network, DSAccess service chooses two domain controllers and one global catalog server to work with. However, on a larger network, the DSAccess service could choose up to 10 domain controllers and 10 global catalog servers. Why does Exchange 2007 need to work with so many Active Directory (AD) servers?

The answer has to do with stability. A server may occasionally fail, a router may go down or any number of other events can make an Exchange server temporarily inaccessible. By maintaining a list of multiple domain controllers and global catalog servers, Exchange can contact Active Directory in several ways if there is a problem contacting a server.

The DSAccess service is designed to perform specific tests every 15 minutes to make Exchange's Active Directory connectivity as reliable as possible. This makes Exchange aware of new domain controllers, changes to AD topology or even server failures and allows it to react accordingly.

The notion that Exchange can fall back on alternate domain controllers if one fails implies that some domain controllers are more important than others. Exchange designates one domain controller as the configuration domain controller. Exchange Server's configuration is written to this domain controller and then replicated to others.

Exchange is designed this way to prevent problems associated with replication latency. If contradictory configuration information was written to two different domain controllers, those controllers would begin replicating to other domain controllers. This would result in mass confusion. Designating a single domain controller to replicate Exchange configuration information solves this problem.

By default, the first domain controller that DSAccess is bound to during the initial dynamic detection process is designated as the configuration domain controller. You can designate a specific domain controller to act as the configuration controller, but I recommend allowing Exchange to choose which one to use. If you manually select a domain controller, Exchange won't automatically select a replacement configuration domain controller if the selected one fails.

If you're curious about which domain controller Exchange is using as a configuration domain controller, you can examine the Event Log entries. To do this, open the event logs and search for Event ID 2150.

About the author: Brien M. Posey, MCSE, is a five-time recipient of Microsoft's Most Valuable Professional (MVP) award for his work with Exchange Server, Windows Server, Internet Information Services (IIS), and File Systems and Storage. Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal website at www.brienposey.com.

Do you have comments on this tip?  Let us know.

Do you know a helpful Exchange Server, Microsoft Outlook or SharePoint tip, timesaver or workaround? Email the editors to talk about writing for SearchExchange.com.

Dig Deeper on Exchange Server setup and troubleshooting

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchServerVirtualization

SearchCloudComputing

SearchSQLServer

SearchEnterpriseDesktop

SearchVirtualDesktop

Close