News Stay informed about the latest enterprise technology news and product updates.

DSAccess for Exchange

In this tip from "15 tips in 15 minutes: Managing recipients and distribution lists," you'll discover the importance of the Exchange service DSAccess and how it works with the DNS, Global Catalog servers, and domain controllers.

Exchange needs access to Active Directory domain controllers for a variety of reasons (see Figure 5.20):

  • Configuration information for the organization. Exchange stores server parameters, mailbox and public folder store parameters, public folder hierarchy, tool parameters, and much more in the Configuration naming context of Active Directory.
  • Recipient information in the Global Catalog. Exchange and Outlook need access to a Global Catalog server to expand group memberships for mail-enabled groups, to obtain address lists such as the GAL, and to obtain recipient information necessary for message handling and routing.
  • Recipient information in a domain. If Exchange can get the information it needs about a recipient from a standard domain controller in its own domain rather than a Global Catalog server, it will do so. This reduces load on the Global Catalog servers.

You are reading tip #5 from "15 tips in 15 minutes: Managing recipients and distribution lists," excerpted from Chapter 5 of the book Learning Exchange Server 2003, published by Addison-Wesley Professional.

An Exchange service called DSAccess has the task of finding domain controllers and Global Catalog servers suitable for use by Exchange. Think of DSAccess as a nightclub owner who books stage talent. It applies a series of tests, the details of which you'll see in a minute, to determine which servers it wants to use. It then selects up to ten domain controllers and ten Global Catalog servers and puts them in a local DSAccess profile. It also selects one domain controller to use for a configuration server. This avoids replication latency issues.

Diagram of DSAccess selection based on location
Figure 5.20 Diagram of DSAccess selection based on location. (Click on image for enlarged view.)

DSAccess keeps an open connection to each server in the DSAccess profile. This avoids the expensive chore of building up and tearing down RPC and TCP connections each time the Exchange server needs information.

Other Exchange services, such as the SMTP Routing Engine Categorizer and DSProxy, send their LDAP and NSPI requests to DSAccess, which selects a target domain controller or Global Catalog server from its profile and forwards the request to that server. It uses a round robin selection process for load balancing.

Because all LDAP queries funnel through DSAccess, Exchange dramatically improves performance by caching the query results. By default, Exchange gives 4MB of physical memory to the DSAccess cache.

Global Catalog advertising and DSAccess

DSAccess uses DNS to locate domain controllers and Global Catalog servers. Figure 5.21 shows an example DNS zone with three GC SRV records located in the _msdcs.dc.gc._tcp folder. Active Directory domain controllers also place copies of these SRV records into individual site folders underneath the _msdcs.dc.gc._sites folder. By looking in the folder corresponding to its own Active Directory site, DSAccess can locate local Global Catalog servers.

SRV records for Global Catalog servers in DNS
Figure 5.21 SRV records for Global Catalog servers in DNS. (Click on image for enlarged view.)

When you configure a domain controller to be a Global Catalog server, the server must replicate the Domain naming contexts from the other domains before it can answer Global Catalog lookup requests authoritatively. Once a newly promoted Global Catalog server has replicated all domain naming contexts, it places an SRV record in DNS that "advertises" itself as available. You can verify the status of the Global Catalog promotion in several ways:

  • Look for an Event log entry saying that the GC promotion has completed (Figure 5.22 shows an example).
  • Look for a Registry entry called HKLM -> System -> CurrentControlSet -> Services -> NTDS -> Parameters -> Global Catalog Promotion Complete (shown in Figure 5.23.) and verify that the value is set to 1.
  • Dump the RootDSE contents using the LDAP Browser (LDP) from the Windows Server 2003 Support Tools and look for the isGlobalCatalogReady attribute set to TRUE.
  • Use the Nltest utility that comes in the Windows Server 2003 Support Tools. The following example shows that the server running Nltest was able to find a Global Catalog server in its local site (Phoenix) in its domain (

    Event Log entry
    Figure 5.22 Event Log entry announcing that a domain controller has successfully begun operating as a Global Catalog server. (Click on image for enlarged view.)

    Registry entry
    Figure 5.23 Registry entry on newly promoted Global Catalog server. (Click on image for enlarged view.)


C:\>nltest / /gc
           DC: \\
      Address: \\
     Dom Guid: 01012378-a008-409d-9696-3c7f16bfbb62
     Dom Name:
  Forest Name:
 Dc Site Name: Phoenix
Our Site Name: Phoenix
DOMAIN DNS_FOREST CLOSE_SITE The command completed successfully
  • Use the Netdiag utility that comes in the Windows Server 2003 Support Tools. The following example shows that the server running Netdiag was able to enumerate all domain controllers, it was able to find a domain controller in the local site (W2K3-S1), and it was unable to contact one of the domain controllers (W2K3-S9):
C: \>netdiag /test:dclist /v

    Gathering IPX configuration information.
    Querying status of the Netcard drivers... Passed
    Testing Domain membership... Passed
    Gathering NetBT configuration information.
    Gathering the list of Domain Controllers for domain Â'COMPANY'

<<<intermediate tests skipped>>>

DC list test . . . . . . . . . . . : Passed

    Find DC in domain 'COMPANY':
    Found this DC in domain 'COMPANY':
        DC. . . . . . . . . . . : \\
        Address . . . . . . . . : \\
        Domain Guid . . . . . . : {01012378-A008-409D-9696-Â3C7F16BFBB62}
        Domain Name . . . . . . :
        Forest Name . . . . . . :
        DC Site Name. . . . . . : Phoenix
        Our Site Name . . . . . : Phoenix
        Flags . . . . . . . . . : GC DS KDC TIMESERV WRITABLE ÂDNS_
DC DNS_DOMAIN DNS_FOREST CLOSE_SITE 0x8 List of DCs in Domain 'COMPANY': (this DC is down) [WARNING] Cannot ping '' (it may be Âdown). The command completed successfully

DSAccess selection criteria

DSAccess performs a series of tests to determine the suitability of a domain controller or Global Catalog server. The first tests determine whether the domain controller or Global Catalog server can respond to Exchange queries:

  • Reachability. The server must respond to an LDAP bind request on TCP port 389 for domain controllers and TCP port 3268 for Global Catalog servers.
  • Replication current flag. DSAccess checks RootDSE on the domain controller to verify that the isSynchronized attribute shows TRUE.
  • Global Catalog flag. DSAccess checks RootDSE on a Global Catalog server to verify that the isGlobalCatalogReady attribute shows TRUE.
  • Server functional test (Netlogon). In this somewhat time-consuming test, DSAccess makes an RPC connection to the Netlogon service at the domain controller and then checks available disk space, time synchronization, and whether the server participates in replication. You can disable this test for front-end servers in front of firewalls. See Chapter 11, "Deploying a Distibuted Architecture," for details.
  • Operating system version. Exchange 2003 requires that all domain controllers used by DSAccess run at least Windows 2000 SP3 or higher.
  • Domain Exchange-Ready. DSAccess looks to see if the Exchange Enterprise Servers group has Manage Auditing and Security Log permissions on the domain controller. This verifies that an administrator has run DomainPrep in the domain and that the changes have replicated to the target domain controller.

The Exchange Support Tools (free download from Microsoft) contains a utility called Policytest that runs the same test as DSAccess to verify that DomainPrep has fully replicated to all domain controllers. It checks to see if the Exchange Enterprise Servers group has been granted the Manage Auditing And Security Logs privilege on each domain controller. You'll need Domain Admin rights to run Policytest. Here's a sample listing for three domain controllers:

Local domain is "" (COMPANY)
Account is "COMPANY\Exchange Enterprise Servers"
  DC      = "W2K3-S1"
  In site = "Phoenix"
  Right found:  "SeSecurityPrivilege"
  DC      = "W2K3-S4"
  In site = "Sydney"
  Right found:  "SeSecurityPrivilege"
  DC      = "W2K3-S9"
  In site = "SaltLakeCity"
  Right found:  "SeSecurityPrivilege"

The next tests determine how DSAccess distributes queries once it has assembled the servers in its profile. DSAccess looks for these configuration settings:

  • Weighting in the SRV records
  • FSMO (Flexible Single Master Operations) roles (See Appendix A, "Building A Stable Exchange 2003 Deployment Infrastructure," for details.)
  • Site where the server resides
  • LDAP query performance
  • LDAP loading based on current number of connections

All things being equal, DSAccess uses round robin to share load among domain controllers and Global Catalog servers. The final checks determine if a Global Catalog server can actually give authoritative answers to queries. DSAccess verifies the following:

  • Global Catalog attribute in the NTDS Settings object for the server set to TRUE
  • Correct number of naming contexts

Viewing DSAccess selection results

Once DSAccess selects its domain controllers and Global Catalog servers, you can view the results in ESM by opening the Properties window for an Exchange server and then selecting the Directory Access tab, as shown in Figure 5.24.

Directory Access tab
Figure 5.24 Directory Access tab in Exchange server Properties window showing selection of domain controllers and Global Catalog servers. (Click on image for enlarged view.)

If you change the selection in the Show dropdown list from All Domain Controllers to one of the other selection options, you can uncheck Automatically Discover Servers and manually select a server or servers for that operation. If you select servers manually, include more than one for fault tolerance. DSAccess does not dynamically select a server if it cannot contact any of the statically configured servers.

Event log entries for DSAccess selection results 

If you enable diagnostic logging for DSAccess in the server Properties window in ESM and set the logging level to Medium, you will see a log entry Event ID 2080 from the MSExchangeDSAccess showing the result of the DSAccess evaluation. Figure 5.25 demonstrates an example.

The evaluation includes 10 tests. It's difficult to see in the Event Properties window, but the test results are displayed as columns. You can click the Copy to Clipboard button and paste the result into Notepad if you want a clearer layout. The first column, Server Name, lists the server's Fully Qualified Domain Name (FQDN). Here's a brief description of the content under each column. For more details, see Microsoft Knowledge Base article 316300.

Event Log entry showing result of DSAccess
Figure 5.25 Event Log entry showing result of DSAccess domain controller evaluation. (Click on image for enlarged view.)

  • Roles. CDG stands for Configuration, Domain Controller, and Global Catalog.
  • Reachability. DSAccess uses a numerical system to show whether it can connect to a server via TCP. A successful connection to a Global Catalog server is represented with a 1, 2 means a successful connection to a domain controller, 4 means a successful connection to a configuration domain controller, and 7 means the sum of the first three.
  • Synchronized. Setting of isSynchronized flag in RootDSE.
  • GC Capable. Setting of isGlobalCatalog flag in RootDSE.
  • PDC. Result of "FSMO" check.
  • SACL Right. Result of "Exchange Ready" check.
  • Critical Data. Verifies that Exchange organization object exists in Configuration naming context.
  • Netlogon. Result of "Netlogon" -- numerical value must match Reachability value.
  • OS Version. Must run at least Windows 2000 SP3 to support all features required by Exchange 2003.

15 tips in 15 minutes: Managing recipients and distribution lists

 Home: Introduction
Tip 1: Exchange security groups
Tip 2: Group membership expansion
Tip 3: Managing Exchange group email properties
Tip 4: Exchange 2003 Query-Based Distribution Groups
Tip 5: DSAccess for Exchange
Tip 6: DSProxy for Exchange
Tip 7: Managing Exchange recipient policies
Tip 8: Exchange Recipient Update Service and proxy addresses
Tip 9: Restricting mail storage on an Exchange server
Tip 10: The Exchange server mailbox management service
Tip 11: Blocking a user's email access
Tip 12: Accessing another user's mailbox in Outlook
Tip 13: Exchange mail retention
Tip 14: Managing recipients with system policies
Tip 15: Managing recipients with Global Settings

This chapter excerpt from Learning Exchange Server 2003 by William Boswell is printed with permission from Addison-Wesley Professional, Copyright 2004. Click here for the chapter download or to purchase the book.

Dig Deeper on Exchange Server setup and troubleshooting

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.