Event logs shed light on Exchange Server DSAccess issues

Exchange Server 2003 uses DSAccess to communicate with Active Directory. However, the distributed nature of Active Directory may make it difficult to get to the root cause of DSAccess issues. Begin the process by analyzing Event 2080 data.

Exchange Server uses DSAccess to communicate with Active Directory. Although this service is generally reliable, Active Directory's distributed nature can complicate troubleshooting if your Exchange organization experiences AD-related problems. The event viewer can help pinpoint the root cause of your problems.

Increasing diagnostic logging

The best place to begin troubleshooting is to analyze Event 2080 in the Application log. This event exists in Exchange 2000 (SP3) and higher, but you must increase the diagnostic logging level before Exchange 2000 or Exchange Server 2003 will display the event.

To increase the diagnostic logging level in Exchange Server 2003, open the Exchange System Manager and navigate through the console tree to: <your organization > -> Administrative Groups > <your administrative group> -> Servers.

Next, right click on the listing for the server that you want to increase the logging level on and then choose Properties. Windows will display a properties sheet for the server.

Select the properties sheet's Diagnostic Logging tab and choose the MSExchangeDSAccess option from the list of services. Next, select Topology from the list of categories on the right. Set the Logging Level to Medium, then click OK (Figure 1). Now you'll need to restart your Exchange server.

Set the topology logging level for the MSExchangeDSAccess Service to Medium
Figure 1. Set the topology logging level for the MSExchangeDSAccess Service to Medium.

After your Exchange server reboots, open the Event Viewer and select the Application log. Look for a log entry with Event ID number 2080. This event contains a wealth of information about the way that Exchange Server uses Active Directory (Figure 2).

Event 2080
Figure 2. This is what Event 2080 looks like in the Event Viewer.

Information presented in the event is specific to that particular Exchange server event log. Every Exchange server within a site should see the same domain controllers. However, there are a number of network issues that can cause Exchange servers to have inconsistent network views. Therefore, if the Active Directory problems you're experiencing seem to be isolated to specific Exchange servers, try generating 2080 events on other Exchange servers and then compare the results.

The anatomy of Event 2080

Although the description provided with Event 2080 may seem cryptic, there is some reasoning behind it. In the description section in Figure 2, you'll notice that the first portion of the text is similar to a database schema. The lower portion contains the actual data. For example, the first field that is defined (after the text indicating that DSAccess has discovered the following servers with the following characteristics) is the Server Name field. The portion of the description that contains the actual data lists three servers: tazmania.production.com, dns.production.com, and gfi-dc.production.com.

The key to reading Event 2080 data is to think of it as a space-delimited file. Spaces within the data portion of the description separate one field from another.

Domain controller roles

The second piece of defined information shows the role of each domain controller. For example, roles associated with server DNS.production.com contain the letters C, D and G. The letter C indicates that the server can be used as a configuration server. The letter D confirms that the server is acting as a domain controller. And the letter G indicates that the domain controller is acting as a global catalog server.

Tazmania.production.com's roles are defined as CD-, meaning that the server is a domain controller that can be used as a configuration server. The dash (-) in the last position indicates that it is not a global catalog server. This shouldn't be a problem since performance problems can occur if you configure all of your domain controllers as global catalog servers.

From an Exchange Server standpoint, you must have a configuration server, a domain controller and a global catalog server. These roles don't all have to exist on the same server as long as each role is performed either in the site containing your Exchange server or in the site closest to the Exchange Server site with the lowest site-link cost.

If some AD roles aren't being performed, try comparing the event with 2080 events on a properly functioning Exchange server. You can also check for domain controllers that aren't listed or have been incorrectly reported as not performing specific roles.

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 Legacy Exchange Server versions