The goal of this blog post is to build some familiarity and understanding of how Exchange uses WMI in representing the Status and Monitoring node in Exchange System Manager.
What is the Monitoring and Status tool?
The Monitoring and Status tool is an administrative tool built into Exchange System Manager that you can use to monitor the status and performance of servers, connectors, and resources. The Monitoring and Status tool has two components:
- Notifications: Use this component to create e-mail or script notifications that are triggered when the status of a server or connector changes.
- Status: Use this component to view the status of servers, connectors, and resources.
In this blog post, I am going to focus more on the "status" of the Exchange server viewing through ESM.
The following status states apply to servers:
- Available - indicates that the server is online and functioning normally.
- Unreachable - indicates that one of the main services on the server is down.
Note - If a server is unreachable and is in a different routing group, it may indicate that a connector between routing groups is down or does not exist.
- In Maintenance Mode - indicates that monitoring is temporarily disabled due to maintenance, backup, repair, or some other reason.
- Unknown - indicates that System Attendant cannot communicate with the local server.
The following status states apply to connectors:
- Available - indicates that the connector is functioning properly.
- Unavailable - indicates that a communication service, such as the routing service, is not functioning on this connector.
If you have configured monitors for specific resources such as SMTP queue or X.400 queue growth, when the threshold for either a warning or a critical error is exceeded, the state change will be displayed in the Status container. For example, when an SMTP queue grows continuously and reaches a critical state, the status container will display "Critical: SMTP queue growth" for the server object that is experiencing the problem.
Components Involved
There is 4 major components involved that interact to provide the server status data that is viewable through ESM.
- Exchange System Manager that shows the status.
- MAD (aka System Attendant, mad.exe) that decides what the status is.
- The routing table provider (exwmi.dll) which replicates the status around the organization.
- WMI which provides the interface between ESM/MAD and the routing table.
Monitoring Architecture
At startup, MAD spawns a monitoring thread which creates and initializes a CMonitoringTask object. This MonitoringTask object contains the WMI query which is used to figure out the state of the server. It is also used to write that state to the routing table (using WMI again).
This thread makes queries to WMI at various intervals to figure out the state of various components (CPU, memory, queues, etc...). Based on that information, MAD will decide what the state of the overall server is. It then writes this server state to its own instance of the WMI class ExchangeServerState.
When the WMI provider (exwmi.dll) receives the ExchangeServerState from MAD, it looks up the routing table and reads the previous state of the server. If there is no difference between the previous state and the one being written, nothing happens. This is important because the routing table replication algorithm doesn't react well to frequent write operations. If the state is different, then it is written to the routing table.
It is important to note that each MAD.exe process on each server monitors only itself (i.e the local machine). It does not monitor the state of other machines since the MAD process on those machines are responsible for local activity. When the information gathered by MAD causes a change to the previous state stored in the routing table, the routing engine on a slave node sends this information to the routing group master for dissemination to the other slave nodes.
When viewing the monitoring status, ESM connects to the WMI of one specific server and reads the ExchangeServerState instances of all servers. The server on which ESM is running is used for the WMI connection if Exchange is detected on it; otherwise the first server name returned from an Active Directory query for all Ex200x servers in the local AG is used. If the routing table is not getting replicated throughout the org, then the state information for some servers may be very stale. If a server is marked as 'Unreachable', it can mean one of two things: either the routing master for that server was unable to contact it, or the WMI server chosen cannot connect to its routing master (in which case all servers will be marked as 'Unreachable'). If you connect ESM to a server that is not connected to its master, then all servers will appear unreachable (since the routing table is stale, we can't use it).
Putting the pieces together
WMI architecture overview:
A provider is a COM object that monitors one or more managed objects for WMI. Similar to a driver, a provider supplies WMI with data from a managed object. A provider also handles messages from WMI to the managed object.
Exchange's providers are contained within these 2 DLLs:
Exmgmt.exe
- Responsible for message tracking, message tracking log location field & dsaccess tab.
- It runs as a standalone process
- owns root\MicrosoftExchangeV2 namespace
Exwmi.dll
- This dll is responsible for monitoring and status node in ESM, monitoring tab on server properties.
- loads under Winmgmt.exe in W2K and in Wmiprvse.exe in W2K3.
- owns root\cimv2\applications\exchange namespace
A managed object is a logical or physical enterprise component, such as a hard drive, network adapter, database system, operating system, process, or service. A managed object communicates with WMI through a WMI provider that calls methods in the COM API for WMI. Some examples of managed objects in the Exchange sense are:
- Contents of the directory access tab
- Message tracking data
- Status and notifications data
A management application or script is an application that interacts with the WMI infrastructure example ESM.
Exchange WMI Providers
Exchange 2000/2003 added three new WMI providers. These providers create a new namespace in the WMI Common Information Model (CIM) repository and add five new WMI classes. Each class is related to a different part of Exchange 2000 and 2003.
- The WMI ExchangeRoutingTable provider creates the ExchangeServerState and ExchangeConnectorState classes. The Exchange Routing Table provider runs on top of the routing API. The purpose of this provider is:
- To publish the status of the local Exchange 200x server in the routing table, based on the monitoring conditions configured with the Exchange System Manager (ESM).
- To retrieve the states of other Exchange 200x servers in the organization from the routing table, based on the monitoring conditions configured with the ESM.
- To publish the states of the Exchange 200x local connectors in the routing table.
- To retrieve the states of other Exchange 200x connectors in the organization from the routing table.
- The WMI ExchangeQueue provider creates the ExchangeLink and ExchangeQueue classes. The Exchange Queue provider runs on top of the Queue API.
- The WMI ExchangeCluster provider creates the ExchangeClusterResource class. The Exchange Cluster Provider runs on top of the Cluster API.
These three providers expose a set of classes available from the root\CIMV2\Applications\Exchange WMI namespace.
- ExchangeServerState - This class retrieves information about the status of relevant services, including memory used, processor type, disk space available, and the mail queue of Exchange 200x servers in an organization. The ExchangeServerState class works in conjunction with the monitoring configuration defined by the Exchange System Manager (ESM). ESM's monitoring section uses this class extensively to monitor servers.
For more information on ExchangeServerState, refer to:
- ExchangeConnectorState - The ExchangeConnectorState class is based on the same principle as the ExchangeServerState class. The ExchangeConnectorState class monitors the connectors in an Exchange organization and publishes their states in the routing table. When this class is interrogated from ESM or by a script, it offers a list of the connectors available from the routing table with their corresponding states.
Both classes retrieve their information from the routing table. This information is available to administrators on any Exchange 200x server in an organization.
- ExchangeLink - This class provides information about link status and properties. The properties include the retry count, the size of the queue waiting for each link, and the link's current state (i.e., unavailable or up). The SMTP routing engine uses this information to determine link-state routing.
- ExchangeQueue - This class provides detailed information about message queues' contents-such as the protocol that the queue uses (i.e., X.400 or SMTP) and the name of the link that the queue is waiting on. A program can enumerate the individual messages in the queue. For example, Exchange System Manager (ESM) can use this function to count the messages in a queue.
- ExchangeClusterResource - This class provides information (in clustered environments only) about the status of a given cluster resource and the name of the Exchange Virtual Server (EVS) that uses that resource.
Soon, I will post another post that will go into troubleshooting ESM "status" problems.