If you would like to read the next article in this series please go to A Closer Look At Directory Service Access (DSAccess) – Part 2.
Since Exchange 2003 relies totally upon Active Directory for correct operation, it comes as no surprise that an Exchange server runs several key components that interact with Active Directory. One of those is the Directory Service Access (DSAccess) component.
What Is DSAccess?
There are many components within Exchange that require access to Active Directory services, such as the information store and the message categorizer. The DSAccess component optimizes the communication between these components and Active Directory.
The Exchange components that need to interact with Active Directory use DSAccess to retrieve Active Directory information rather than communicating directly with domain controllers and global catalog servers. As a result, DSAccess is therefore a very important part of Exchange. DSAccess is good for system performance, since it maintains a cache that effectively reduces the number of LDAP queries that these Exchange server components make to Active Directory. This is good for query speed as well as load reduction on both domain controllers and global catalog servers. Note, though, that Global Address List (GAL) lookups from Outlook clients do not use this cache.
It’s the System Attendant service that initializes DSAccess, which comes in the form of a Dynamic Link Library (DLL) file DSACCESS.DLL. In addition to DSACCESS.DLL there are two other associated DLLs, DSCMGS.DLL and DSCPERF.DLL. DSCMGS.DLL contains the information DSAccess uses to write event log entries, whilst DSCPERF.DLL contains performance object information.
To see which processes are using DSACCESS.DLL, you can use TASKLIST.EXE (Windows 2003 and Windows XP) or TLIST.EXE (older versions of Windows) for from a command line by running the following command on your Exchange server:
tasklist –m dsaccess.dll
You should see output similar to that shown in Figure 1, where you can see that processes such as the Information Store (store.exe) and the System Attendant (mad.exe) are using DSACCESS.DLL.
Figure 1: Processes Using DSACCESS.DLL
In essence, DSAccess performs a discovery process to determine the Active Directory topology and then chooses suitable Active Directory domain controllers and global catalog servers that can be used by Exchange. I will discuss which domain controllers and global catalog servers DSAccess thinks are suitable later on in this article. Once it has chosen suitable servers, DSAccess then maintains an ongoing list of the valid servers that Exchange can use.
Prior to Exchange 2000 SP2, the utility DSADIAG.EXE could be used to list the domain controllers, global catalogs and configuration domain controller that were being used by DSAccess. From Exchange 2000 SP2 onwards, the DSADIAG.EXE functionality has been incorporated into Exchange System Manager so you don’t need to go hunting for DSADIAG.EXE now. DSAccess information can now be seen on each Exchange server by running Exchange System Manager and opening the properties for your Exchange server(s). The information is exposed in the Directory Access tab as shown below in Figure 2. Note though, that the Microsoft Exchange Management service must be running to obtain all information via the Directory Access tab.
Figure 2: Directory Access Properties Tab
One thing that is worth noting is that ordinarily, DSAccess is capable of failover. In other words, if one of the global catalog servers or domain controllers that is being used by Exchange services were to fail, those services would continue to run by virtue of the fact that they would failover to use a different global catalog server or domain controller. However, if you are running Exchange on a domain controller, this failover will not take place; this is by design. This is one of the core reasons why it’s not necessarily a good idea to run Exchange on a domain controller.
Server Selection
DSAccess splits Active Directory servers into three distinct types: global catalog servers, domain controllers and the configuration domain controller. All three server types are vital to the correct operation of an Exchange infrastructure. Global catalog servers are used for forest-wide searches, domain controllers are used to obtain local domain information, whilst the configuration domain controller is chosen to ensure that configuration changes are written to a single domain controller only.
DSAccess will choose up to 10 global catalog and domain controller servers from the local Active Directory site. If no suitable global catalog or domain controller servers are found within the local Active Directory site, DSAccess will choose servers in remote Active Directory sites although it will fail back to local site servers as soon as possible; as you might expect, local site global catalog and domain controller servers are preferred. Both lists of chosen servers are re-evaluated every 15 minutes unless servers are hard-coded into the registry, in which case the hard-coded servers are merely tested for suitability. I will cover more on the hard-coding of servers later. The configuration domain controller role is re-evaluated every 8 hours by default.
So how exactly does DSAccess choose its list of servers? Well, a series of suitability tests are performed by DSAccess. They are as follows:
- Is the server contactable? DSAccess will check to see if the server is contactable over port 389 if the server is a domain controller, or 3268 if the server is a global catalog server. You will no doubt recognize these as the LDAP port numbers.
- Is the server synchronized? Here DSAccess checks that the server is fully synchronized by checking the isSynchronized attribute found in rootDSE of the server.
- Is the server a global catalog server? This is a similar check to the server synchronization check in that it is performed by checking the isGlobalCatalogReady attribute found in rootDSE of the server.
- Can the security access control list permission of the configuration naming context be read? DSAccess considers the server unsuitable if it cannot successfully do this.
- Is the server in a domain where Exchange DomainPrep has been run? It is a requirement that the server being tested for suitability exists in a domain where Exchange DomainPrep has completed successfully.
- Is the server generally suitable? Here DSAccess queries the Netlogon service via a RPC call. The idea behind this test is that if the server being tested is experiencing any general problems it will not be suitable.
- Is the server running Windows Server 2003 or Windows 2000 SP3 or higher? These are the valid operating system versions of global catalog or domain controller servers for use by DSAcess.
These tests are known as hard tests. After these have completed, DSAccess does actually run a few soft tests to ensure that the servers being tested are capable of handling the load that Exchange 2003 will place on them. Such tests include testing the response times for LDAP queries made to these servers. Reputedly, any server taking longer than 2 seconds to respond to these LDAP queries will fail the soft test and will therefore be removed from the list of suitable servers. One interesting tweak that can be made is restricting the PDC Emulator from the list of servers that DSAccess can use. As I’m sure you know, the PDC Emulator is one of the five Flexible Single Master Operation (FSMO) roles found in Active Directory and in certain situations the PDC Emulator can experience heavy loads. If you want to ensure that the PDC Emulator will not be used, you can implement the following registry modification:
Key: HKLM\System\CurrentControlSet\Services\MSExchangeDSAccess\Profiles\Default
Value: MinUserDc
Type: REG_DWORD
Set the value to be the minimum number of domain controllers that should be detected in the same Active Directory site before the PDC Emulator is excluded by DSAccess. To stop the PDC Emulator from being used completely, set the registry value to 1. If you want more information on this, then check out Gerod Serafin’s blog article, or Microsoft KB article 298879.
Summary
So far in part 1 of this two-part article we’ve covered what DSAccess is and how it chooses domain controllers and global catalog servers for use by Exchange. In part 2 we’ll take a look at how you can see the results of the tests that DSAccess performs, hard coding servers, cache information and a brief look at some performance counter information.
If you would like to read the next article in this series please go to A Closer Look At Directory Service Access (DSAccess) – Part 2.
