Please let others know how useful this tip is via the rating scale at the end of it. Do you have a useful Exchange or Outlook tip, timesaver or workaround to share? Submit it to our tip contest and you could win a prize.
When Microsoft began using Active Directory as a repository for Exchange-related data in Exchange 2000 (and now Exchange 2003), it had to set up some rules of engagement. Specifically, Exchange Server needed to communicate with Active Directory in a way that wouldn't create excessive network traffic or overwhelm domain controllers with too many LDAP requests.
To circumvent these issues, Microsoft created a component called DSAccess to act as an intermediary that could regulate traffic flow between Exchange Server and Active Directory.
DSAccess
DSAccess is an API used by all Exchange Server components to query Active Directory and acquire configuration and recipient information. Some of the many Microsoft Exchange components that depend on DSAccess are the Exchange System Attendant, Message Transfer Agent and Exchange information store.
DSAccess is a generic name assigned to a group of DLLs -- DSAccess.dll, Dscmgs.dll, and Dscperf.dll -- that are collectively known as DSAccess, or the DSAccess cache.
The DSAccess cache is actually made up of two separate caches:
- The configuration cache
The configuration cache is used to store information pertaining to configuration data, including store and routing objects. It is set to 5 MB by default.
When the system boots, DSAccess initiates a discovery process designed to identify the Active Directory topology (primarily related to the site structure), the domain controllers, and which domain controllers act as global catalog servers.
DSAccess repeats this discovery process every 15 minutes to check for configuration changes and verify that the known domain controllers are still available. Whenever Exchange Server needs to access a domain controller or a global catalog server, it consults the DSAccess cache to determine which server is the best fit for the job.
- The user object cache
By default, Exchange Server sets aside 140 MB for the user object cache, which obviously stores user data. Objects within this cache are flushed when the cache fills up or when the object's TTL expires. The default TTL for user objects is five minutes.
The user object cache is designed to prevent excessive LDAP queries. When Exchange Server needs to know something about a user, it checks the DSAccess cache first to see if the information is already stored there.
If the information is cached, then Exchange uses the cached copy instead of issuing an LDAP query. If the required information is not cached, Exchange has to retrieves the necessary information from the domain controller via an LDAP query and stores the results in the DSACache.
About the author: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Exchange Server, and has previously received Microsoft's MVP award for Windows Server and Internet Information Server (IIS). 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 Web site at http://www.brienposey.com.
Do you have comments on this tip? Let us know.
Related information from SearchExchange.com:
Tip: A deeper look at how DSAccess works
15 tips in 15 minutes: Managing recipients and distribution lists
Reference Center: Exchange and Active Directory tips and resources
