Exchange 2000 SP2’s DSAccess Component

Microsoft Exchange 2000 Server introduced fundamental architectural changes such as Store partitioning and off-loading of protocol support to Microsoft IIS. But jettisoning Exchange's Directory Service (DS) and permissions model in favor of Windows 2000 Active Directory (AD) is perhaps the most fundamental change of all. Exchange Server 5.5's DS is under the control of one application, whereas AD is a general-purpose directory designed for application use as well as OS use. The sidebar "Local Directories vs. Directory Service," page 46, summarizes the major differences between DS and AD.

A vital part of Exchange 2000, the DSAccess component, manages Exchange 2000's interaction with AD. For Service Pack 2 (SP2), Microsoft rewrote 60 percent of the code in DSAccess. Such an exhaustive rewrite calls for a look at the work DSAccess does and at how the upgraded component affects the workings of Exchange 2000.

The Role of DSAccess
To reduce the complexity of large applications, OS developers commonly write components that other components can call to accomplish a specific task. DSAccess provides an API that components such as the Store can use to query AD. DSAccess also manages a cache of recently accessed AD data. This cache improves query performance and reduces the load on AD by resolving many queries before they reach AD. DSAccess is also responsible for discovering domain controllers (DCs) and Global Catalogs (GCs) and determining which of them an Exchange server should use.

Because directory access is a fundamental necessity for a messaging system, DSAccess is one of the most crucial parts of Exchange 2000. If DSAccess fails or if Exchange 2000 encounters problems (e.g., a network interruption) while accessing a DC or GC, other components can't work. In particular, when the routing engine can't determine the list of DCs and GCs to work with, it can't process messages because it can't validate email addresses. Symptoms of problems with DSAccess include the accumulation of messages in message queues, poor performance when Exchange 2000 expands distribution groups, and clients that appear to hang when they attempt to access AD.

Some messaging components can work without DSAccess. Microsoft equips all Win2K servers with a basic SMTP service (as part of IIS), and some applications can use that service. Microsoft SharePoint Portal Server 2001, for example, uses the SMTP service to send email subscription notifications when someone posts new documents to folders in the SharePoint Store. The basic SMTP service can also expand Win2K distribution groups to determine addresses for message delivery without relying on DSAccess. As a general rule, however, all Exchange components use DSAccess whenever possible, and installing Exchange 2000 upgrades the SMTP service to let it use DSAccess.

Selecting DCs and GCs for DSAccess
When a server starts Exchange 2000 services, DSAccess selects (from a list of available DCs) a DC to use for configuration lookups in AD, such as locating other Exchange servers in the organization and the connectors that link servers together. Microsoft calls this DC the configuration domain controller. Because so much Exchange 2000 configuration information resides in AD and the configuration DC handles approximately 30 percent of all calls to DSAccess, the configuration DC plays an important role in configuration lookups.

Because of the load that lookups generate on AD, the results of all configuration lookups go to the cache I mentioned earlier. The cache lets DSAccess handle many subsequent calls without increasing the load on the configuration DC. Before SP2, the cache had a 5-minute timeout. Because configuration data remains relatively stable after you deploy Win2K and Exchange 2000, SP2 increases the cache's default timeout to 15 minutes. You can change this value through the registry, as the sidebar "Manually Setting DSAccess Parameters," page 48, explains.

DSAccess builds the list of available DCs through an automatic topology-detection process that looks for suitable DCs that are in the same Win2K site as the Exchange 2000 server. Because all DCs in a forest share the same configuration data, any DC in the forest—even a DC that isn't in the same domain as the Exchange 2000 server—can become the configuration DC. However, DSAccess includes in the list of available DCs only those that are in a domain in which you've run the DomainPrep procedure. (DomainPrep is the part of the Exchange 2000 installation procedure that prepares a domain to host Exchange 2000 servers.)

If DSAccess can't find a suitable DC in the site, the selection process expands its search to look for a suitable DC in other sites. Alternatively, you can select a DC through the Exchange 2000 server's Directory Access properties page or, as I explain in "Manually Setting DSAccess Parameters," you can edit the registry to force DSAccess to use a specific DC. (You need to be careful about making this change in the registry, however. Because you can easily forget that you changed the registry, registry changes tend to become permanent, in effect, and can cause problems down the line—should you want to change the configuration DC after a new DC joins the network, for example.) If the configuration DC later becomes unavailable, DSAccess again uses the topology-detection process to attempt to locate and connect to another DC.

The Microsoft Management Console (MMC) Exchange System Manager (ESM) snap-in also uses the configuration DC to query AD for information about the Exchange organization and to make changes (e.g., change server properties, apply system policies to administrative groups, add a new routing connector) to the configuration. Remember, ESM no longer handles details about mailboxes and users—with Exchange 2000, AD stores that information as properties of user and group objects and processes it through the MMC Active Directory Users and Computers snap-in.

DSAccess also uses automatic topology detection to build a list of suitable GCs for retrieving AD information. Fast access to recipient information is necessary for Exchange components such as the routing engine to resolve addresses, expand group membership, and route messages. Clients also need fast response when they look for a recipient in the Global Address List (GAL) or through a Lightweight Directory Access Protocol (LDAP) query. DSAccess looks for GCs in the same Win2K site as the Exchange 2000 server; the topology-detection process looks outside the site only if it can't find a local GC. Note that unlike in DC selection, Windows domains play no role in identifying suitable GCs; every GC in the forest holds the recipient data that Exchange needs.

DSAccess rebuilds the GC list automatically every 10 hours (an interval based on the standard Kerberos timeout) or when a change is made to the GC in the local site. After building the list, DSAccess attempts to balance the request load across all available GCs and uses a cache to hold the results of recipient lookups. You can also tweak the rebuild interval through the registry, as "Manually Setting DSAccess Parameters" explains.

When you understand how automatic topology detection works, which Exchange components rely on DC and GC availability, the size of the load placed on DCs and GCs, and the performance problems that occur if network glitches prevent servers from communicating, you can derive a simple set of best practices for placing GCs on your network. Those practices are as follows:

• Make sure to put at least one GC and one DC in every Win2K site that hosts an Exchange server (one computer can handle both roles).
• Make sure that every Exchange 2000 server is in close network proximity to a DC and a GC. In other words, if you can't ensure that Exchange will have fast access over a network link to a DC or GC that's in another physical location, install a DC or GC locally.
• Make sure that a GC is available for every four Exchange servers that you deploy in a site. As the number of Exchange servers grows, monitor the load on the GCs and take steps to ensure that performance isn't slowed because a GC is unavailable or has an excessive load.
• Ensure that a suitable DC or GC is available to handle a failover should the preferred DC or GC experience a problem.

Determining the Servers Used
How can you determine what AD servers an Exchange server is using? Before SP2, the answer was to use the Dsadiag utility, an unsupported command-line utility that reports some basic information about available DCs and GCs.

SP2 provides a new Directory Access tab on the Exchange server's properties page, as Figure 1 shows. This new tab is a significant improvement over the Dsadiag utility, which you no longer need to use. Now, you can simply access the properties page through ESM, click the Directory Access tab, and view and set the DCs and GCs that DSAccess uses.

DSAccess Changes in SP2
In addition to the longer timeout for configuration lookups and the new Directory Access tab on a server's Properties page, SP2 has made other improvements to DSAccess. Some of the more significant changes are as follows:

• If more than 10 DCs and GCs exist in the local Win2K site, you can load-balance requests across all of them.
• SP2 better handles failover to another DC or GC, so controller outages have a smaller impact on Exchange 2000 and on clients. This improvement is partly because of an improvement in the way DSAccess selects an out-of-site controller. Previously, DSAccess could choose any controller in the network to fail over to, whereas SP2 uses Windows site links and costs to determine the best controller.
• Under SP2, DSAccess monitors a failed local DC or GC. If the controller comes back online within 5 minutes, DSAccess automatically reconnects to the controller.
• In an especially welcome improvement, SP2 provides diagnostic logging to help you troubleshoot problems.
• SP2 better supports front-end and back-end configurations by eliminating the requirement that Exchange servers use remote procedure calls (RPCs) to connect to DCs and GCs that are hosted outside the demilitarized zone (DMZ).
• Suitability testing determines whether selected DCs and GCs are functioning correctly before DSAccess uses them. This enhancement deserves a little more discussion.

Suitability Tests
SP2's suitability tests help Exchange 2000 decide whether an AD server (a DC or a GC) is suitable for DSAccess to use. Before SP2, DSAccess used a simple test (i.e., a query to port 389 or 3268) to determine whether a server was offering AD service. DSAccess would use any server that responded to the test, even if the server was a heavily loaded GC, a DC in a remote site across a slow connection, or a server that hadn't fully replicated the contents of AD. All these scenarios cause problems for Exchange—message routing slows, users experience timeouts when clients attempt to access the GAL, and messages might even be sent to outdated addresses.

The suitability tests verify that the server is contactable, that it responds to queries in a timely manner, and that it offers services that DSAccess can use. The tests are in three categories: hard tests, soft tests, and side tests.

• Hard tests determine whether DSAccess can use a server. If a server fails these tests, DSAccess ignores it. For example, if a server isn't reachable through port 389 (for a DC) or 3268 (for a GC), DSAccess recognizes that the server isn't an AD server. To prevent DSAccess from connecting to an unsynchronized copy of AD and using outdated information, other hard tests determine whether the AD data on the server is synchronized and participating in typical replication activities.
• Soft tests determine the optimum servers for DSAccess to use. For example, one test determines whether a server is in the same Win2K site as the Exchange server. Other tests 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's heavily loaded because slow responses to AD queries will delay processing of messages through the routing engine. Similarly, DSAccess will avoid a server that holds an Operations or Flexible Single-Master Operation (FSMO) role for the domain or forest because such a server is also likely to be under a heavy load.
• Side tests determine whether DSAccess can use a server as a DC or GC.

If you go to an Exchange 2000 server's Properties page and select a Logging level of Minimum or higher for the Topology category of a server's MSExchangeDSAccess service, as Figure 2 shows, DSAccess reports suitability-test results in Application log event ID 2080. Figure 3 shows a sample of the information that event ID 2080 provides. You'll need a little information to interpret these results.

The servers that DSAccess discovers are divided into two groups: those that are in the same Win2K site as the Exchange server and those that are outside the site. For each server, the log shows the following results:

• The server name—for example, dbogceu01.emea.cpqcorp.net.
• The roles that the server can fulfill. D indicates that the server is a DC, G indicates a GC, and C means that the server is acting as the configuration DC. CDG means that the selected server can fulfill all three roles.
• Whether the server is reachable. This value is a bit mask. A value of 0 indicates that the server is unreachable and that DSAccess can't use it. A value of 1 means that the server is reachable as a GC through port 3268, 2 means that it's reachable as a DC through port 389, and 4 means that the server can act as a configuration DC (also through port 389). A value of 7 (1 + 2 + 4) indicates that the server is reachable through all ports and can act in any role.
• Whether the server is synchronized. A value of 1 means that the GC is synchronized, a value of 2 means that the DC is synchronized, and a value of 4 indicates that the configuration DC is synchronized. A value of 7 means that all possible synchronization has taken place.
• Whether the server is capable of acting as a GC. A value of 1 indicates that the server can be a GC; 0 indicates that it can't.
• Whether the server is the PDC emulator for a domain. A value of 0 indicates that the server isn't a PDC emulator; 1 indicates that it is.
• Whether the server passes the system ACL (SACL) test. The SACL test determines whether the server resides in a domain that you've prepared for Exchange 2000 by running the DomainPrep part of the Exchange 2000 installation program. A value of 1 indicates that the server passes the SACL test; 0 indicates that it doesn't.
• Whether the server hosts crucial data. A value of 1 indicates that the Microsoft Exchange container exists within the configuration naming context (NC) on this DC; a value of 0 indicates that it doesn't. The Exchange container stores crucial data (e.g., server names, routing group information, connectors) that must be available for routing to work. DSAccess won't select a DC that doesn't host this container.

A Valuable Upgrade
DSAccess is a crucial Exchange 2000 component that servers and clients alike rely on. In SP2, Microsoft has done a good job of understanding the problems with the early version of DSAccess and responding with an upgraded version—DSAccess on steroids. The only pity is that we waited longer than a year to get the new code. If you aren't sure whether to upgrade servers to SP2, DSAccess provides reasons to move as quickly as possible, especially if you operate large or distributed Exchange 2000 environments.