XGEN: Architecture of the Exchange Resource Dynamic Link Library (Exres.dll)

This article describes the architecture and function of the Microsoft Exchange Resource dynamic link library (DLL) file, Exres.dll.

Exres.dll is an Exchange-specific resource DLL. The Microsoft Cluster Service (MSCS) communicates through a resource monitor to Exres.dll, and Exres.dll then communicates with the Exchange components. Exres.dll translates the cluster actions, such as "resource online" and "resource offline" into the starting and stopping of Exchange-related services. Exres.dll also monitors the stopping of these resources and notifies the Cluster service if the operation is unsuccessful.

Exres.dll

In a cluster, the Cluster service is responsible for starting and stopping services through Exres.dll. Because of this, an administrator should not stop a service from the command-line. When you stop a service from the command-line, the IsAlive call to that service does not work, and because of this, the Cluster service tries to bring that service back online. The IsAlive function is implemented to return the last value that was pooled from the resource health-monitoring thread. The LooksAlive function has the same implementation as IsAlive, and is not called because Exres.dll provides resource-failure event handles to the cluster resource monitor that tells when a resource has failed. The health-monitoring thread checks resources every 10 seconds, and you cannot configure this check. The Excluadm.dll program provides cluster-specific Wizards and the user interface (UI) that is associated with Exchange.

Exchange Resources

An Exchange virtual server (EVS) is a collection of Exchange resources. Each resource has all the properties that a Microsoft Windows 2000 resource has, such as dependencies, possible owners, and retry properties. Each resource in the EVS represents a different component of Exchange. The possible Exchange-specific resources are the following:

• System Attendant (SA)
• Information Store (IS)
• Protocols
  • SMTP
  • HTTP
  • POP3
  • IMAP4
• Routing
• Message Tracking Agent (MTA)
• MSSearch
  This resource is managed by its own resource DLL, Gathercl.dll.

For each resource, the IsAlive and LooksAlive calls that the Cluster service makes to that resource are the same. Each of these Exchange resources have dependencies as shown in the following diagram, where the arrows point to the resource that the resource depends on:

Exchange Resource Dependencies

System Attendant

The default dependencies that are shown in the previous diagram are created when the System Attendant is created. The System Attendant is the fundamental resource that controls the creation and deletion of all the resources in an Exchange virtual server. These resources are created when you create the System Attendant resource. To delete the server and its object from Active Directory, delete the System Attendant. The IsAlive call to the System Attendant checks the Service Control Manager (Service_Control_Interogate) to obtain the immediate state of the System Attendant.

Information Store

When the Information Store is brought online, the Information Store service (Store.exe) starts and begins to mount the storage groups. When all the storage groups are mounted and the store has "played" all the transaction logs, the resource is considered to be online. The IsAlive call to the Information Store sends a Remote Procedure Call (RPC) call to the Store.exe process. On the Store process side, the check consists only of verifying that the virtual server name exists in the list of active virtual servers.

Message Transfer Agent

The Message Transfer Agent (MTA) resource is an Active/Passive resource. There can be only one MTA per cluster. The MTA is created in the first Exchange virtual server (EVS) and cannot be moved to a different EVS. Although the MTA is an Active/Passive resource, it serves all virtual servers in the cluster while it is online. The IsAlive call to the Message Transfer Agent checks the Service Control Manager (Service_Control_Interogate) to obtain the immediate state of the MTA.

Protocols (SMTP, POP3, IMAP, HTTP)

The IsAlive call acts in the same way for all the protocols. Exres.dll opens a TCP socket port to the protocol by using the bindings that are provided from the Internet Information Services (IIS) metabase and waits for a response in the form of a banner. If the start of the banner matches the expected value, the resource is considered to be online. If the banner is not returned before the time-out period, the Cluster service determines that the protocol virtual server is unavailable and the IsAlive call is unsuccessful. None of the protocols can be set to reject all connections from all servers or the protocol virtual server will reject IsAlive calls from itself. Because of this, each protocol virtual server must accept connections from its own IP address. For the HTTP protocol, Exres.dll sends a GET command to obtain a response.

When an Exchange virtual server is brought into an offline state such as in a planned failover, all instances of the SMTP protocol virtual server on the node are stopped. This causes the SMTP resource of other Exchange virtual servers to quickly go offline and restart. The SMTP resource does not restart automatically if the Do not restart option is selected in its properties.

Routing

The IsAlive call to the Routing resource checks the Service Control Manager to determine if the Routing service is running.

Content Indexing

The MSSearch resource provides content indexing for the Exchange virtual servers. The IsAlive call to the MSSearch process returns a pointer to the data structure for the database that is being indexed. If the pointer is valid, the resource is determined to be working correctly. To re-create the MSSearch resource after it has been deleted, you must delete and then re-create the Information Store resource for that Exchange virtual server.

Active/Active Architecture

To make Exchange 2000 Server cluster-aware, multiple storage groups and protocol virtual servers are used. This section describes in more detail how Active/Active clustering is implemented.

Use a cluster node with one Exchange virtual server as an example, and that virtual server has one storage group that is associated with it. The protocols are associated with the IP address and network name of the virtual server, and not the cluster node itself. If another Exchange virtual server in the cluster fail over to this node, the Store.exe process mounts the storage groups that are associated with this new virtual server, and then creates additional protocol virtual servers to use to respond to the IP address and network name resource of the second Exchange virtual server.

A stand-alone server cannot have more than four storage groups mounted and active at a time. Because of this, you must monitor the number of storage groups in a cluster. The limitation of four storage groups applies to a single cluster node. No matter how many Exchange virtual servers are failed over to a single node, the Store.exe process can mount no more than four storage groups.

ExchangeOpen/ExchangeClose Functions

The ExchangeOpen and ExchangeClose functions are called whenever the Exchange resources are moved to the current node. Inside the ExchangeOpen functions, memory is initialized or allocated for the basic information of the resource. These functions also handle the loading and unloading of DLL files that are used by the Resource DLL, and this is controlled by reference counters.

ExchangeOnline/ExchangeOffline Functions

The ExchangeOnline and ExchangeOffline functions create new OnlineWrapperThread and OfflineWrapperThread worker-threads and then immediately return an ERROR_IO_PENDING to the cluster resource monitor. To prevent situations where Remote Procedure Calls stop responding (hang), these two worker threads create the real online/offline thread. The Wrapper threads act as monitors for the online/offline thread, and uses timers to monitor the operation of the online/offline thread. If the online/offline thread does not return in the PendingTimeOut value that was set in the Cluster administrator, the Wrapper thread determines that the operation has been unsuccessful, and sets the resource's state as "failed". It then returns an error. The only exceptions to this behavior are for upgrade operations or for store resource online operations. In these two cases, the Wrapper thread waits for an upgrade to complete or for a store resource to go online, without timing out.

When the Wrapper thread returns a failure to the resource monitor, the resource monitor tries to restart the resource an additional two times. During this time, the ExchangeOnline function checks to see if the previous online/offline thread has returned. If the online/offline thread does not return, the ExchangeOnline function returns.

For the OfflineWrapperThread, if the ExchangeOffline thread does not return in the PendingTimeOut limit, for the Store, System Attendant, and MTA resources, the resource monitor terminates the corresponding process.

The ExchangeOnlineThread/ExchangeOfflineThread performs the following the Exchange resources:

• System Attendant, Information Store, and Routing:
  Starts the service if it is not already started, and then makes RPC calls to each of the services to start or stop the corresponding virtual server instance.
• Protocol Resources:
  Sets the command bit in the IIS metabase, and then starts the service if it has not already been started. The corresponding service picks up the command, and then starts or stops the virtual server. The only exception to this is the SMTP virtual server. In this case, the whole SMTP service must be stopped when a virtual server instance is taken offline. The IsAlive function checks for other virtual servers running on the same physical computer, detects that the underlying SMTP service is stopped, and then restarts the virtual server.

ExchangeIsAlive and ExchangeLookIsAlive

The ExchangeOnline function returns an event handle to the resource monitor, and the resource monitor then stops calling the LookIsAlive function. Instead, the resource monitor calls the ExchangeIsAlive function at intervals that are set in the Cluster Administrator "Looks Alive" polling interval. Whenever a resource is online, The Exchange resource DLL creates two threads for that resource to monitor the status of that resource. The first thread, called ExchangeIsAliveMonitor, checks the status of the resource every 10 seconds by waking the second thread, called ExchangeCheckIsAliveWrapper. ExchangeCheckIsAliveWrapper performs the actual IsAlive checking. If the ExchangeCheckIsAliveWrapper thread does not return in the PendingTimeOut limit, or if the IsAlive check is unsuccessful, the ExchangeIsAliveMonitor thread signals a failure event for the particular resource to the resource monitor. The ExchangeIsAlive function returns the status of the last IsAlive check.

ExchangeTerminate

This function terminates the existing ExchangeIsAliveMonitor thread and for the Store, System Attendant, and MTA resources, also performs the corresponding offline procedure to make sure that the database is dismounted. If the offline procedure does not complete successfully in the PendingTimeOut limit, the Resource DLL also terminates the corresponding process.

Creating Resources

When the user creates a resource first, and then creates a call to Excluadm.dll prompting for information, Excluadm.dll obtains all the required information for the resource, passes it to the Cluster service, and then the resource monitor creates a call to the ExchangeResourceControl function in the resource DLL with the information that was passed from Excluadm.dll and Clusctl_Resource_Set_Private_Properties as the control code. ExchangeSetPrivateResProperties is used to handle this control code. It first saves the information to the cluster database under the

Parameters

registry key for that resource, and then makes a call to Exsetdata.dll to have Exsetdata.dll create objects in Active Directory. In some cases, a problem may occur and some configuration information may be modified in Exchange System Manager, without having the changes synchronized with the cluster database.