Manage Learn to apply best practices and optimize your operations.

An introduction to the DSAccess service in Exchange Server 2007

Exchange Server is extremely dependent on Active Directory and in an effort to make sure Active Directory and Exchange 2007 run as smoothly together as possible, Microsoft created DSAccess service. Get an introduction to DSAccess service in this tip and see which tests it performs to make sure Active Directory and Exchange Server 2007 are running together as effectively as possible.

Since Exchange Server depends on Active Directory, Microsoft had to design the server so it could submit LDAP queries to Active Directory without overburdening domain controllers. To do this, Microsoft created the DSAccess service. This tip explains the DSAccess service and its relation to Exchange Server 2007.

The DSAccess service is one of the most critical services that Exchange Server uses. Its job is to monitor Active Directory (AD) and make Exchange Server aware of the current AD topology. While the architectural elements of various Exchange Server products are important, you can't see exactly what they're doing. The DSAccess service tells Exchange which domain controllers to use and allows administrators to see which controllers and global catalog servers are active.

If you want to see the choices that DSAccess has made, open the Exchange Management Console and expand the Server Configuration container. Beneath this container, you will see containers for each Exchange Server 2007 role. Select the container for the role associated with the server you want to examine. The details pane will display a list of all Exchange 2007 servers that are assigned to that role.

Right-click on the listing for the server that you want and choose Properties from the menu. Exchange to display the server's properties sheet. If you go to the System Settings tab, you'll see a list of the domain controllers and the global catalog servers that Exchange is using, as shown in Figure 1. Exchange
Figure 1. The Exchange Management Console shows which domain controllers are being used.

This raises the question of why Exchange is using these particular domain controllers. In a small organization with only a few domain controllers, the answer is obvious. Those are the only domain controllers on the network, so Exchange has no choice but to use them. But on larger networks, Exchange will only use some of the available domain controllers.

Exchange is designed to use the domain controllers and global catalog servers that are the most suitable. To determine which to use, the DSAccess service performs 10 different tests on each domain controller. You can see the results of these tests by looking for Event ID 2080 in your System log.

Figure 2 shows what these tests and their results look like. The section that starts with the words Server Name lists the 10 different tests that are performed. Test results are then listed for each server and are grouped by site.

DSAccess service test results
Figure 2. The codes to the right of the server names are an indication of the test results.

The event log entry lists all servers in the same site as the Exchange server that generated the event. It then lists servers located in a different site. To the right of the individual server names are a series of codes, which indicate test results.

The following table shows tests that the DSAccess service performs and explanations of their results:

Test Explanation
Roles The roles test tells you what roles the domain controller is performing. There are three different codes listed in the results section. Typically, you will see a combination of these codes listed for each server. The codes that are used include:

C -- Configuration
D -- Domain Controller
G -- Global Catalog

If you look at Figure 2, you will notice that the server Tazmania uses the codes CD-. The dash in the G position indicates that the server cannot be used as a global catalog server.

Reachability The reachability test indicates whether or not the domain controller is reachable over specific TCP ports. Here is an example of what each test result means:

1 - The server is reachable as a global catalog server over port 3268.
2 - The server is reachable as a domain controller over port 389.
3 - The server is reachable as a global catalog server and as a domain controller.
4 - The server is reachable as a configuration domain controller.
7 - The server is reachable as a global catalog server, a domain controller and a configuration domain controller.

Synchronized The synchronized test tells you whether or not the RootDSE flag indicates synchronization.

1 - The flag is set to True.
0 - The flag is set to False.

GC Capable The GC capable column tells you whether or not the server is a global catalog server.

1 - The server is a global catalog server.
0 - The server is not a global catalog server.

PDC The PDC column tells you whether or not the domain controller is hosting the PDC emulator role for the domain.

1 - The domain controller is the PDC emulator.
0 - The domain controller is not the PDC emulator.

SACL Right The SACL right column tells you whether or not the DSAccess service has the permissions needed to read the SACL portion of the NT Security Descriptor on the domain controller.

1 - DSAccess has the necessary rights.
0 - DSAccess does not have the required rights.

Critical Data The critical data column confirms that the domain controller is aware of the Exchange organization and that it contains a copy of critical Exchange Server-related objects.

1 - The domain controller is aware of critical Exchange Server objects.
0 - The domain controller does not know about some of the required Exchange Server objects.

NetLogon The NetLogon test (first introduced in Exchange 2000 SP3) confirms that the DSAccess service was able to connect to the domain controller's RPC service using Remote Procedure Calls (RPC). Keep in mind that a failure may not necessarily indicate a server problem, but could be due to a firewall that is blocking an RPC request. The codes used by the NetLogon test are:

1 - The NetLogon check was successful for the global catalog server role.
2 - The NetLogon check was successful for the domain controller role.
3 - The NetLogon check was successful for the global catalog server and the domain controller roles.
4 - The NetLogon check was successful for the configuration domain controller role.
7 - The NetLogon check was successful for the global catalog server, domain controller and the configuration domain controller roles.

OS Version The OS version test (first introduced in Exchange 2003) confirms that the domain controller is running Windows 2000 Server with SP3 or higher or a later Windows Server OS.

1 - The domain controller meets Exchange Server's OS requirements.
0 - The domain controller's OS is too outdated to be used by Exchange.

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

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

Please let others know how useful this tip was via the rating scale below. Do you know a helpful Exchange Server, Microsoft Outlook or SharePoint tip, timesaver or workaround? Email the editors to talk about writing for

This was last published in June 2009

Dig Deeper on Legacy Exchange Server versions

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.