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:
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:
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.
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:
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.