After an extensive rewrite, DSAccess services are much improved
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.
Prev. page
[1]
2
3
next page 
