In Exchange 2003, for example, you cannot mount the databases unless the Exchange System Attendant service is running. The Exchange information store is also dependent on the Exchange System Attendant service. Even in previous versions of Exchange Server, various Exchange-related services fail to start unless the Exchange System Attendant is running.
In this tutorial, I provide an overview of how the Exchange System Attendant works and explain the purpose and functionality of each of its subcomponents.
TABLE OF CONTENTS
Overview of the Microsoft Exchange System Attendant
The DSAccess component
The DSProxy component
The Recipient Update Service
The Mailbox Manager component
The Server Monitor component
The Offline Address Book Generator
The Free/Busy component
The Metabase Update Service
Overview of the Microsoft Exchange System Attendant
The Microsoft Exchange System Attendant service performs a wide variety of tasks. It is responsible for everything from facilitating Active Directory communications to enforcing retention policies and mailbox quotas.
As you might expect from such a diverse service, the Exchange System Attendant is based on a primary executable file that runs as a service and a number of subcomponents that allow the Exchange System Attendant to perform various tasks.
Exchange System Attendant's main executable file is the MAD.EXE file, located in the Exchange server's Program Files\Exchsrvr\Bin folder. But most of the subcomponents exist as .DLL files.
Exchange System Attendant is more than just a collection of subcomponents, though, since the service itself does have a task to perform.
Microsoft Windows servers make use of a built-in computer account that is used to assign various permissions at the machine level. In order for an Exchange 2003 server to have the necessary Active Directory permissions, its computer account must be a member of the Exchange Domain Servers global security group.
The Exchange System Attendant's job is to make sure that the computer account is indeed a member of this global security group.
There are two internal Exchange System Attendant components used to help Exchange Server locate domain controllers.
When an Exchange Server component, such as the Exchange store or the SMTP Transport Engine, needs to acquire recipient information from Active Directory, the query is routed through the DSAccess component. As such, the DSAccess component acts as a proxy for these Active Directory requests.
DSAccess retrieves the requested information, caches the result, and then passes the result back to the component that requested the information. The DSAccess cache helps to reduce the number of queries that Exchange has to make against the domain controllers.
The other Active Directory-related component of the Exchange System Attendant is DSProxy (DSProxy.DLL).
While DSAccess proxies Active Directory requests coming from other Exchange Server components, DSProxy acts as a proxy for Active Directory queries coming from Microsoft Outlook clients.
When a client running Microsoft Outlook 2000 -- or a later version of Outlook -- performs an operation that requires an Active Directory query (such as a request to retrieve the Global Address List), the DSProxy component refers the client to the global catalog server so the client can communicate with it directly.
If a client is running an older version of Outlook, the DSProxy component will act as a true proxy. Older versions of Outlook are incapable of communicating directly with a global catalog server, so DSProxy performs the operation on behalf of the client.
The Recipient Update Service (Abv_dg.DLL), which applies recipient polices to mail-enabled user objects, is actually a subcomponent of the Exchange System Attendant.
Mailbox Manager componentThe Mailbox Manager's job is to enforce policies that help to control the size of an information store, including mailbox quotas and message retention policies.
Server Monitor component
Exchange Server maintains link state information so that it can make intelligent, dynamic routing decisions, rather than simply relying on static entries in a routing table. The Server Monitor component of Exchange System Attendant is primary used to keep Exchange Server's link state information up to date.
Exchange 2003 propagates link state information among the servers within the Exchange organization. This process ensures that every server in the organization has up-to-date information regarding which links are available. Exchange uses this link state information to calculate the optimal path to various destinations within the Exchange organization, while still taking into account things like link costs and hop counts.
The Server Monitor component also has a couple of other responsibilities that are not related to maintaining link state information. As the name implies, it is responsible for monitoring server resources using Windows Management Instrumentation (WMI). It is also responsible for managing message tracking logs (assuming that message tracking is enabled).
Offline Address Book Generator
The idea behind the Offline Address Book Generator (OABgen.DLL), another subcomponent of the Exchange System Attendant, is that mobile users sometimes need access to the address book, even when they are not connected to Exchange Server. Since offline users cannot retrieve the GAL through the usual means, they rely on the Offline Address Book (OAB).
The OABgen.DLL file is stored in an Exchange public folder subfolder called Offline Address Book. Exchange makes it possible to have multiple Offline Address Books. Each Offline Address Book contains two subfolders: OAB Version 2 and OAB Version 3a.
The actual address book information is stored as attachments to posts within these folders. These attachments can store a full OAB, or a subset of the additions and changes that have been made since the last full OAB was generated.
Most of Exchange System Attendant's functions discussed so far have had to do with low-level Exchange Server management and message routing. Although it seems a little out of place, the Exchange System Attendant is also involved in publishing free/busy information.
Exchange Server allows users to plan meetings based around the schedules of other meeting attendees. In order to be able to tell when a meeting attendee is free, Exchange needs to be able to read free/busy data from that attendee's calendar.
Since users don't generally have access to other users' mailboxes, the free/busy data is stored in a public folder instead of a user's mailbox. Like the Offline Address Book Generator, the Free/Busy component (Madfb.DLL) is stored in a subfolder of the system public folder named SCHEDULE+ FREE BUSY.
When a user creates an appointment in Outlook Web Access (OWA), the Exchange store sends the corresponding free/busy information to the Exchange System Attendant mailbox. The Madfb.DLL file extracts the free/busy data from these messages and publishes it in the SCHEDULE+ FREE BUSY folder.
In order to really understand what the Metabase Update Service (Ds2mb.DLL) component does, you have to understand a little bit about the Internet Information Services (IIS) metabase.
The IIS metabase is a file that stores IIS configuration information. This configuration file is one of the core components of IIS, and IIS cannot function without it. Given that Exchange Server depends on IIS, Exchange is also dependent on the IIS metabase.
In Windows Server 2003, the IIS metabase exists in the form of an XML file named Metabase.XML. There is also a corresponding schema file named MBSchema.XML.
In Windows 2000 Server, the IIS metabase is stored in a binary file named Metabase.BIN. In both operating systems, the IIS metabase is located in the System Root\System32\inetsrv folder.Exchange Server has its own configuration information. Some Exchange configuration information related to SMTP virtual servers, the HTTP configuration for OWA, and a few other Exchange components, are stored in Active Directory, but are needed by IIS.
This is where the Metabase Update Service comes into play. This service replicates protocol-related Exchange Server configuration information from the Active Directory to the IIS metabase.
|ABOUT THE AUTHOR:|
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Exchange Server, and has previously received Microsoft's MVP award for Windows Server and Internet Information Server (IIS). Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at www.brienposey.com.
This was first published in October 2007