Should we use windows services to manage Exchange related services? This has been asked few times, which made me to research online resources. I have decided to post TechNet post without making many changes I hope below Microsoft article will make all of us understand the key DLL files (EXRES.DLL and some of the internal functions such as IsAlive function, and ExchangeOpen functions)
- Exchange 2003 is cluster-aware and provides its own cluster resource DLL, named EXRES.DLL, for communication and interaction with the Windows Cluster service. The Windows Cluster service communicates through Resource Monitor to EXRES.DLL, and EXRES.DLL then communicates with the Exchange components. EXRES.DLL translates the cluster actions into actions for Exchange-related services. EXRES.DLL also monitors the stopping of these resources and notifies the Cluster service if the operation is unsuccessful. The following figure illustrates the relationship between EXRES.DLL and the Cluster service
- In a cluster, the Cluster service is responsible for starting and stopping Exchange services through EXRES.DLL. Because of this, an administrator should not stop a service from the command-line, the Windows Services snap-in, a Resource Kit tool, or a third-party application.
- When you stop a service outside of the Cluster, the IsAlive call to that service fails, causing the Cluster service to attempt a restart of the stopped service. The IsAlive function returns the last value that was pooled from the resource health-monitoring thread.
- The LooksAlive function has the same implementation as IsAlive. The Looks Alive function is not called, because the EXRES.DLL provides resource-failure event handles to the cluster Resource Monitor that indicates when a resource fails.
- The health-monitoring thread checks resources every ten seconds. This resource check cannot be configured. EXCLUADM.DLL provides the interface associated with Exchange and cluster-specific wizards
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. This process is controlled by reference counters.
ExchangeOnline and ExchangeOffline Functions
The ExchangeOnline and ExchangeOffline functions create new OnlineWrapperThread and OfflineWrapperThread worker threads and immediately return an ERROR_IO_PENDING to the cluster Resource Monitor. When the wrapper thread returns a failure to Resource Monitor, Resource Monitor tries to restart the resource two additional times. During these restart attempts, the ExchangeOnline function determines if the previous online/offline thread is returned. If the online/offline thread is not returned, the ExchangeOnline function restarts.
For the OfflineWrapperThread, if the ExchangeOffline thread does not return in the PendingTimeOut limit for the Store, System Attendant, and MTA resources, Resource Monitor ends the corresponding process.
To prevent situations in which RPCs hang, these two worker threads create the real online/offline thread. The wrapper threads act as monitors for the online/offline thread and use 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 Cluster Administrator, the wrapper thread determines that the operation is 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.
The ExchangeOnlineThread and ExchangeOfflineThread service the following Exchange resources:
- Micrsoft Exchange System Attendant service, Microsoft Exchange Information Store service, and Routing Each of these resources starts the service (if it is not already started), and then makes RPC calls to each of the services, instructing them to start or stop the corresponding Exchange Virtual Server.
- Protocol Resources Protocol resources set the command bit in the IIS metabase, and then start the service, if it has not already started. The corresponding service picks up the command and 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 ExchangeLooksAlive
The ExchangeOnline function returns an event handle to Resource Monitor, and Resource Monitor then stops calling the ExchangeLooksAlive function. Instead, the Resource Monitor calls the ExchangeIsAlive function at intervals set in the Cluster Administrator Looks Alive polling interval. Whenever a resource is online, EXRES.DLL creates two threads to monitor the status of that resource. The first thread, named ExchangeIsAliveMonitor, checks the status of the resource every ten seconds by waking the second thread, named 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 Resource Monitor. The ExchangeIsAlive function returns the status of the last IsAlive check.
This function ends the existing ExchangeIsAliveMonitor thread. For the Exchange store, System Attendant, and MTA resources, it 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, EXRES.DLL also terminates the corresponding process.
The user creates a resource first, and then creates a call to EXCLUADM.DLL, prompting for information. EXCLUADM.DLL obtains the required information for the resource and passes it to the Cluster service. Resource Monitor creates a call to the ExchangeResourceControl function in EXRES.DLL. This call contains 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 Acitve Directory. In some cases, a problem might occur and some configuration information might be modified in Exchange System Manager, without synchronizing the changes with the cluster database.
http://technet.microsoft.com/en-us/library/bb124768.aspx
Best
Oz Ozugurlu
No comments:
Post a Comment