2.6 DSAccess-Exchange s directory access component

---

2.6 DSAccess-Exchange's directory access component

To reduce complexity in large applications it is common to create code for a specific purpose for use by other components. Microsoft designed DSAccess to manage the interaction between Exchange 2000/2003 and the AD by providing an API to components such as the Store to make queries to the AD without having to write their own access code. DSAccess also manages a cache of AD data-essentially recently accessed data-to improve query performance by checking queries against the cache before searching the AD. The default size of the cache is 50 MB, divided into recipient data (essentially mail-enabled objects recently looked up in the AD) and configuration data about the Exchange organization. The shared cache reduces the load on the AD by eliminating queries that can be satisfied by cached data. Given the number of email addresses in message headers that it must validate and then use to decide what destination queue to place messages on, the Exchange Routing Engine is a major consumer of the DSAccess cache. The Routing Engine also needs to know about available messaging connectors, information that comes from the configuration data in the AD. In fact, without such a cache, the overall performance and message throughput of the Routing Engine would be very impaired, so you can see why this cache is so important to Exchange. Usually, you can leave DSAccess to manage its cache automatically, but a number of registry values are available to control how quickly items expire in the cache and how much memory Exchange allocates to the cache (Table 2.7). It is always better for system performance if an application can fetch data from memory instead of going to disk, so increasing the size of the DSAccess cache can be beneficial by reducing disk I/O and CPU usage. You should consider increasing the cache size for servers that operate inside large organizations (where it is less likely that any particular address is held in a standard size cache) or servers equipped with more than 1 GB of memory. Before changing anything, make sure that you evaluate how these values influence system performance for a test server. Make the changes at HKLM\System\CurrentControlSet\ Services\MSExchangeDSAccess\Instance0.

Table 2.7: Registry Values that Affect DSAccess

Value	Meaning
CacheTTLUser (DWORD)	The expiration interval for the recipient cache set in seconds.
MaxEntriesUser (DWORD)	The maximum number of entries held in the cache. A value of 0 means the cache is only limited by its size.
MaxMemoryUser (DWORD)	The maximum amount of memory (in bytes) allocated to hold data about recipients. For example, a value of 58,720,256 means 50 MB. The maximum value is 0x000170A3 (equivalent to 94 MB).
CacheTTLConfig (DWORD)	The expiration interval for the configuration cache set in seconds.
MaxEntriesConfig (DWORD)	The maximum number of entries held in the configuration cache.
MaxMemoryConfig (DWORD)	The maximum amount of memory (in bytes) allocated to hold configuration data.

While you can adjust the overall size of the cache, you cannot adjust the maximum size of an object's attribute that the cache can hold (32 KB). In most circumstances, this size is perfectly adequate, but you can exceed the maximum if you deploy Exchange 2000 or 2003 in more than 100 domains in a forest. The number of domains is approximate and you can exceed this value, depending on the exact configuration. Microsoft Knowledge Base article 813814 provides background to the problem, which is due to the need to build ACLs for objects held in the cache. If an object's ACL grows past 32 KB, DSAccess cannot cache it and must then contact a DC or GC to retrieve the attributes of the affected objects whenever it needs to use one. As you can imagine, if the affected objects have anything to do with mail routing or are popular points for user access (such as a public folder), a server can consume a lot of bandwidth and processing to validate objects. This problem negates the value of the cache and normally affects the speed with which Exchange can process messages, thus leading to large queues. The good news is that this problem only appears in the largest Exchange deployments and only if you mail enable large numbers of domains. This problem underlines the need to follow best practice to simplify your AD structure as much as possible and to never mail enable a domain (by running DomainPrep) unless you need to host an Exchange server there. Note that the ACEs do not exist until you install the first Exchange server into the domain.

Microsoft Knowledge Base article 327378 explains another aspect of DSAccess in action. In this case, Exchange 2000 servers do not enforce mailbox quotas quickly. The default value of the user object cache (controlled by the CacheTTLUser registry value) causes the cache to be refreshed after ten minutes, which is acceptable for routing information. The cached data interacts with another cache in the Store that holds information (like quotas) about mailboxes. The Store refreshes its mailbox information cache every two hours. In some situations, it can be beneficial to follow the directions in the Knowledge Base article to adjust how the Store and DSAccess caches interact if you find that servers do not pick up updates to mailbox information quickly.

Although you might assume that they would gain a performance benefit, clients do not use the contents of the DSAccess recipient cache. In fact, this is logical, because clients use the most up-to-date recipient information or use a proxy (prior to Outlook 2000 SR2) or referral mechanism to locate a GC whenever access to recipient information is required.

Microsoft continues to learn from real-life deployments and to improve DSAccess performance. Their own figures reveal a 20 percent drop in LDAP traffic between Exchange and GCs after organizations deployed SP3. Microsoft made further improvements in Exchange 2003, especially when you deploy Exchange in conjunction with Windows 2003 DCs and GCs to allow Exchange 2003 servers to take advantage of some performance improvements in the AD and a new feature called the GC logon cache.

2.6.1 DSAccess tasks

Apart from managing the contents of its cache, the major role of the DSAccess component is to find and control the set of DCs and GCs that Exchange uses when it needs to retrieve information from the directory. This role breaks down into a number of tasks:

• Perform suitability testing to determine that selected DCs and GCs function correctly before DSAccess uses them.

• Manage load balancing of LDAP requests within the local AD site if more than ten DCs and GCs are present.

• Perform graceful failovers to a new DC or GC to minimize the impact on clients and other Exchange components (such as the Routing Engine). DSAccess uses information about Windows site links and connection costs to determine the most appropriate controller to fail over to.

• In failover situations, DSAccess monitors for the local DC or GC to come back online. If this happens within five minutes, DSAccess automatically reconnects to that controller.

• Diagnostic logging to help troubleshoot problems.

We have already concluded that directory access is a fundamental need for a messaging system, so it is therefore obvious that DSAccess is one of the most critical parts of Exchange. If DSAccess fails or a network interruption occurs, other components cannot work; in particular, the Routing Engine will not be able to determine the list of DCs and GCs to work with so it will not be able to process messages, since the Routing Engine cannot validate email addresses. Other problem symptoms include the accumulation of large message queues (because the Routing Engine cannot move the messages off the queues), poor performance when expanding distribution groups, and clients that appear to "hang" when they attempt to access the directory.

Some messaging components can work without DSAccess. All Windows 2000 and 2003 servers are equipped with a basic SMTP service (part of IIS) and Routing Engine for use by applications that need to generate and send messages. For example, SharePoint Portal Server uses the SMTP service to send email subscription notifications when authors post new documents to folders in the SharePoint Store. The processing performed by the SMTP service to expand a Windows distribution group to determine the addresses for message delivery is another example. The Exchange installation program upgrades the standard SMTP components when it installs Exchange; afterward the Routing Engine and other components use DSAccess whenever possible.

2.6.2 Selecting DCs and GCs for DSAccess

When an Exchange server starts its services, DSAccess selects a single DC from the list of available DCs to use for configuration lookups, such as locating other Exchange servers in the organization and the connectors that link servers together. Exchange refers to this DC as the Configuration Domain Controller and it is a critical element, since this DC handles approximately 30 percent of all calls made to DSAccess. For this reason, all results of configuration lookups are held in a cache with a five-minute timeout so many subsequent calls can be handled from the cache rather than creating extra load on the DC. SP2 increases the default timeout value for this cache to 15 minutes-you can change the value through the registry (see the details in Table 2.7). This is a reasonable step to take, since configuration data is typically stable after the initial deployment/migration period. Microsoft made further performance improvements for DSAccess in Exchange 2000 SP3 by reducing the number of LDAP calls between servers and controllers.

ESM also uses the configuration DC to query the AD for information about the Exchange organization and make whatever changes it needs, such as updating server properties, applying policies to an administrative group, or adding new routing connectors. Remember, ESM only deals with the details of the Exchange configuration-administrative groups, routing groups, connectors, databases, and so on. The AD Users and Computers console processes users, contacts, and groups (including details of user mailboxes).

How can you determine what domain controllers an Exchange server uses? Up to Exchange 2000 SP2, the answer was DSADIAG, an unsupported command-line utility that lists some basic information about DSAccess. All Exchange servers now have a Directory Access property page that you can view through ESM to allow you to view and set the DCs and GCs used by DSAccess (Figure 2.18).

Figure 2.18: Directory access property page.

DSAccess builds the list of DCs through an automatic topology detection process, which searches for suitable DCs that are in the same Windows site as the Exchange server. Exchange can select any suitable DC as the configuration DC regardless of whether it is in the same domain as the Exchange server, since all DCs in a forest share the same configuration data. However, a DC will not be included in the list of suitable DCs if you have not run the DomainPrep procedure in its domain. If DSAccess cannot find a suitable DC in the same site, the selection process expands its search to look for any suitable DC in other sites. Alternatively, you can force DSAccess to use a specific DC through a registry setting (see Table 2.8) or by selecting a DC through the Directory Access property page for a server. However, be careful about making changes in the registry, since they tend to become permanent and may not necessarily be the best configuration, especially if new controllers join the network. If the chosen DC becomes unavailable later on, DSAccess attempts to locate another DC and connect to it using the same topology detection process.

Table 2.8: Registry Values to Allocate a Specific GC and DC for DSAccess

Value	Data
For UserGC1:
IsGC (DWORD)	1 (is a GC)
Hostname (REG_SZ)	FQDN of the GC (e.g., gc1.acme.com)
PortNumber (DWORD)	3268 decimal (the IP port to contact the GC)
For UserDC1:
IsGC (DWORD)	0 (only a DC)
HostName (REG_SZ)	FQDN of the DC
PortNumber (DWORD)	389 decimal

Let us assume that you are brave and you want to tell DSAccess the DCs and GCs that you want it to use. In this example, we define one GC and one DC. You define in a set of values under a subkey. The subkey for the first GC is "UserGC1," or "UserDC1" for the first DC. If you want to define other controllers, you set up subkeys for UserDC2, UserDC3, UserDC4, and UserGC2, UserGC3, UserGC4, and so on. Define these values under HKLM\System\CurrentControlSet\MSExchangeDSAccess\ Profiles\Default. Table 2.8 lists the set of values for the new GC and DC.

Other registry settings exist to allow you to implement a static mapping of the ports used by NSPI (Name Services Protocol Interface) and RFR (Referral Services). Outlook clients use NSPI and RFR to connect to the GAL, and sometimes you may wish to direct them to a specific port, especially if they access Exchange through a firewall. On an Exchange server, the registry values are set at: HKLM\System\CurrentControlSet\Services\ MsExchangeSA\Parameters.

Set the port for NSPI in the DWORD value "TCP/IP NSPI Port" and for RFR in the DWORD value "TCP/IP Port." On a GC, you can also force a static mapping of the NSPI port by inserting a similar "TCP/IP Port" DWORD value at HKLM\System\CurrentControlSet\Services\ NTDS\Parameters.

2.6.3 Automatic topology detection

DSAccess usually exploits automatic topology detection to build a list of suitable GCs. Generally, we want to ensure fast access to recipient information to allow Exchange components such as the Routing Engine to resolve addresses, expand group membership, and route messages. Clients also need good response when they look for a recipient in the GAL or via an LDAP query. DSAccess prefers GCs in the same Windows site, and topology detection only goes outside the site if DSAccess cannot find a local GC.

When this happens, the overall performance of an Exchange server may be slower, since it has to communicate across an extended network link each time it needs to retrieve information from a DC or GC. However, the overall impact on performance is mitigated, because Exchange always uses its local cache of directory information first and therefore only needs to make a network call to the directory when it cannot find information in the local cache. When the local controller comes back online, Exchange notices its presence and automatically switches back to use the local system without affecting server operations or clients, an area that Microsoft improved in Exchange 2003. Note that unlike DC selection, Windows domains play no role in identifying suitable GCs, since every GC in the forest holds the recipient data that Exchange needs.

DSAccess automatically rebuilds the GC list every ten hours (this value is based on the standard Kerberos timeout) or if a change occurs in the set of available GCs in the local site. Once it builds the list, DSAccess attempts to balance the load across all available GCs and uses a cache to hold the results of recipient lookups.

The Exchange 2003 installation program supports the /choosedc switch. Microsoft introduced this switch to avoid the problems that sometimes occurred in Exchange 2000 when the server selected a remote DC. While the installation still worked, selecting a remote DC slows things down. You can now use /choosedc to select the optimum DC for an installation, usually one that is near (in network terms) to the server where you are installing Exchange.

2.6.4 Directory suitability tests

The suitability tests provide some interesting background into how DSAccess goes about locating and selecting AD servers. Microsoft introduced the concept of "suitability" to determine whether an Exchange server should use a specific GC or DC server in Exchange 2000 SP2 and implemented the idea in a set of tests. Previously, DSAccess was quite happy to use a DC or GC if it responded to a query to port 389 or 3268-a simple test to see whether a server is offering an AD service. Unfortunately, deployment experience demonstrated that it is all too easy to end up with situations where Exchange connects to a heavily loaded GC, a DC in a remote site across a low-bandwidth connection, or a server that has not fully replicated the contents of the AD. All of these scenarios cause problems for Exchange-routing of messages slows, users experience timeouts when clients attempt to access the GAL, and users might even end up sending messages to outdated addresses.

The suitability tests verify that the server is contactable, responds to queries in a timely manner, and offers services that DSAccess can use. DSAccess divides the tests into three categories:

• Hard: determines whether it is possible for DSAccess to use a server. If a server fails these tests, DSAccess will not select it. For example, if the server is not reachable over port 389 (DC) or 3268 (GC), then it obviously is not an AD server. DSAccess also performs tests to determine whether the AD data on the server is synchronized and participating in normal replication activities, since it would be unwise for DSAccess to connect to an unsynchronized copy of the AD; Exchange would then conduct routing and other critical activities based on outdated information. Exchange also examines the DNS weights and priorities set through SRV records when it tests a server.

  Additionally, DSAccess uses Internet Control Message Protocol (ICMP) pings to determine whether GCs and DCs are "alive." In a front-end/back-end configuration, where the front-end servers are located in a DMZ and the back-end servers are inside the perimeter, it is common practice to disable ICMP traffic to avoid hacker attacks. When this happens, the pings fail, so DSAccess assumes that none of the DCs and GCs in its current topology map is available and therefore begins to examine the network again to discover new controllers to use. You can disable ICMP pings by setting a registry key, as described in Microsoft Knowledge Base article 320529.

• Soft: determines the optimum servers for DSAccess to use. For example, DSAccess always prefers to use a server that is in the same Windows 2000 site as the Exchange server. DSAccess also performs tests to determine the load on the server by measuring the speed with which the server responds to LDAP queries and the number of outstanding LDAP queries. DSAccess prefers not to connect to a server that is already heavily loaded, because slow responses from AD queries will slow processing of messages through the Routing Engine. For the same reason, DSAccess avoids a server that holds one of the operations or Flexible Single Master Operations (FSMO) roles for the domain or forest whenever possible, since these servers are also likely to be under load.

• Side: determines the role (DC or GC) that a server can fulfill. For example, is the server a GC?

If you turn diagnostic logging up to minimum (or greater) for the Topology component of the MSExchangeDSAccess service on a server (Figure 2.19), DSAccess reports the results of the suitability tests in the detail for event 2080 in the Application Event Log. As you can see in Figure 2.20, the results reported into the event log are not immediately obvious, but you can interpret the data as explained in the following text. Remember to tone down diagnostic logging after you recover as much data as you need; otherwise, the application event log quickly fills with DSAccess diagnostics.

Figure 2.19: Setting diagnostics for DSAccess.

Figure 2.20: Event 2080-DSAccess suitability report.

Exchange divides the servers discovered by DSAccess into those that are in the same Windows site as the Exchange server and those that are outside the site. You will see the following data returned for each server that DSAccess examines:

• The name of the server: A list of the FQDNs of the controllers that are available inside and outside the Exchange server's Windows site- for example, dc1.europe.acme.net.

• The roles that this server can fulfill: D indicates that the server is a DC, G means GC, C means that the server is acting as the Configuration DC. In this case, CDG means that the selected server is able to act as the Configuration DC, DC, and GC.

• Whether or not the server is reachable: This value is a bit mask, where 1 means that the server is reachable as a GC through port 3268, 2 means that it is reachable as a DC through port 389, and 4 means that it can act as a configuration DC (also through port 389). A value of 7 indicates that the server is reachable through all ports and can act in any role. A value of 0 indicates that the server is completely unreachable and therefore DSAccess cannot use it.

• Whether or not the server is synchronized: The same bit mask values are used, so 1 means that the GC is synchronized, 2 that the DC is synchronized, and 4 that the configuration DC is synchronized. A value of 7 means that the server is completely synchronized.

• Whether the server is capable of acting as a GC: 1 indicates that it is.

• Whether or not the server is the PDC emulator for a domain: 0 indicates that it is not.

• Whether the server passes the SACL (System Access Control List) test: This test determines whether the server resides inside a domain that you have prepared for Exchange by running the DomainPrep part of the Exchange installation program. A value of 1 indicates that the SACL test passed.

• Whether the server hosts critical data: A value of 1 indicates that the Microsoft Exchange container exists in the configuration NC on this DC. The Exchange container stores critical data, such as server names, routing group information, connectors, and so on, that must be available for routing to work. DSAccess only selects a DC if it hosts this container.

On Windows 2003 servers with Exchange 2003, you see two additional figures. The first indicates whether the server responds to the Netlogon service, the second whether it is running Windows 2003.

You can gain additional information about the DSAccess component through the WMI ExchangeDSAccessProvider provider. Apart from the information reported through the normal UI, the WMI provider allows you to view other details, including:

• The number of asynchronous (nonblocking) connections that are currently open between Exchange and the DC

• The number of synchronous (blocking) connections that are currently open between Exchange and the DC

• How the DC was detected by DSAccess (manual or automatic)

• The type of directory (Active Directory or Exchange 5.5 DS) hosted by the DC

• Whether the DC responds to LDAP requests issued by Exchange in two seconds or less

DSAccess depends on DNS service (SRV) records to learn about available DCs and GCs. After they boot, controllers advertise their capabilities by publishing SRV records in DNS. Table 2.9 lists the common SRV records published by GCs and DCs. You can influence the preference DSAccess has for a particular controller by changing its SRV weighting. Controllers with a low weighting are preferred to those with a high weighting. You can also configure GCs not to announce their availability in DNS.

Table 2.9: DNS SRV Records Published by Windows Controllers

Mnemonic	DNS SRV Record
LDAP	_ldap._tcp._<DnsDomainName>
DCByGUID	_ldap._tcp.<DomainGuid>.domains._msdcs.<DnsForestName>
KDC	_kerberos._tcp._dc._msdcs.<DnsDomainName>
DC	_ldap._tcp.dc._msdcs.<DnsDomainName>
GC	_ldap._tcp.gc._msdcs.<DnsForestName>
GenericGC	_gc._tcp.<DnsForestName>

With Windows 2000 servers, you have to configure these settings in the registry, whereas you can use a Group Policy Object in Windows 2003, which makes life easier if you have to get down to this level of detail.

---