ESM's Monitoring and Status Tools
ESM includes the Monitoring and Status node (under the Tools node). I can honestly say that most Exchange administrators I've met have never used these tools, which is too bad. Although they aren't a complete replacement for a package such as MOM, they provide some useful built-in functionality. Let's start with the Status node, which Figure 2 shows. It gives you a summary status of all Exchange connectors and servers in your organization. Connectors are shown as either up or down; if you see a down connector, you'll have to manually check the virtual server that's hosting it and the machine on the remote end because ESM doesn't tell you where the problem lies. The Winroute tool can be useful in this case because it can display the link state routing table, which might tell you where the problem lies.
The other things that the Status node can monitor will probably be of more interest. By default, each server has a status component called Default Microsoft Exchange Services; this component uses Windows Management Instrumentation (WMI) to watch the state of the Information Store, Message Transfer Agent (MTA) stacks, routing engine, System Attendant, SMTP virtual server, and IIS Web services. If any of those services stops, the state of the monitoring item changes to critical, which can trigger notifications in ESM—unfortunately, you have to be watching the Status node to get updates. These services are all checked via WMI, however, which can introduce some reporting latency. For example, when I stop the MTA on one server and restart it within a minute or two, ESM on another server might not catch the outage. So if you use this monitoring item, be sure to press F5 every so often to force ESM to update itself. You can also create your own status monitors that are based on any of the six resource types that ESM supports.
The available virtual memory type lets you set a threshold percentage for virtual memory use. If your server exceeds the threshold and stays above it for the period you specify, updates in the Status node will notify you. You can set both warning and critical limits, which gives you a way to get early warning of resource shortages.
The CPU utilization type lets you monitor overall CPU use for a server by using the same threshold and duration mechanism as the available virtual memory type. You can't monitor the use of individual CPUs in a multiprocessor system, only the aggregate use.
The free disk space type lets you monitor an individual drive and receive an alert if the space available drops below the value you specify. This function is quite useful for transaction-log volumes because you really don't want to run out of space on those disks.
The SMTP queue growth and X.400 queue growth types give you a way to monitor queues for growth. If any queue of the specified type grows steadily for the specified period, you'll be notified.
Use the Windows service status type to monitor arbitrary services. If the services you want to monitor are Exchange-related but aren't included in the Default Microsoft Exchange Services object, add them to that object; otherwise, create your own.
The Notifications node lets you trigger email messages or scripts when a monitoring item enters the critical or warning state. By right-clicking this node, you can choose the New E-Mail Action or New Script Action commands; in turn, those commands display a Properties dialog box, as Figure 3 shows. You can select which server will perform the monitoring, which servers and connectors you want to monitor (one server or connector, all servers or connectors in a routing group, or a custom-specified set of servers or connectors), and what you want the email message to say when a notification occurs. Of course, you have to be pretty comfortable with the idea of sending critical notifications about the health of your email system through your email system before this task is workable. It isn't the best way, for example, to notify you that your server has fallen over dead (unless you use each server to watch its peers; unfortunately, you have to manually set up that task).
Script-based notifications work much the same way. You can use a regular VBScript script or an executable, and when the servers or connectors you're monitoring enter the selected critical or warning state, the script or executable is launched with the command-line options you specify. Doing so is a good way to use a third-party pager or SMS notification tool or to run a script that does something interesting. For example, you can easily write a small script to send a notification to an Ambient Orb or Dashboard device or a Microsoft SPOT smart watch; the script gives you clear notification—not via email—that something's amiss.
Setting a Notification for SMTP Queue Growth
To set up a notification that will alert you via a script when your SMTP queues start to grow beyond their typical limits, use the following steps:
- Launch ESM.
- Open the Properties dialog box for the server you want to monitor, and switch to the Monitoring tab.
- Click the Add button.
- Select SMTP queue growth from the Add Resource dialog box, then click OK.
- In the SMTP Queue Thresholds dialog box, make sure that the Warning state (minutes) and Critical state (minutes) check boxes are selected, then enter the number of minutes of queue growth you want to trigger each state. Click OK when you're done.
- Click OK to dismiss the Properties dialog box.
- Expand the Tools node.
- Expand the Monitoring and Status node, right-click the Notifications folder, and choose the New, Script notification command.
- Click Select to identify the server you want to perform the monitoring.
- If you chose a different server from the one you selected in step 2, make sure that you choose the correct server to monitor.
- Enter the path and command-line options for your script, then click OK to start the monitoring process.
Message Tracking
Message tracking might not sound like a monitoring tool, but you can use it as a rough way to measure your servers' health. I sometimes find that I don't get messages when I expect to, either because no one (not even spammers) is sending me mail or because of an actual problem with my Exchange infrastructure. One quick way I can determine the problem is to fire up the Message Tracking Center in ESM's Tools node and perform a quick scan of my SMTP bridgehead server, looking for messages within the suspect time period. In conjunction with checking the logs on my Barracuda Spam Firewall appliance, doing so quickly lets me know whether mail is arriving as usual. If not, the track will often indicate where the message went astray. Combined with the ability to get notifications when a connector seems to be down, this monitoring tool is useful. (For more details, see "In the Know: Message Tracking" InstantDoc ID 47996.)
What Isn't Included
What if you want to monitor or control something that isn't included with ESM? You have two avenues of attack. One is to turn to the WMI interfaces that are included with Windows and Exchange and write your own scripts to monitor what you want. This task is a daunting prospect if you've never scripted before, but it isn't that difficult. Pick up Microsoft's Windows 2000 Scripting Guide and Alain Lissoir's two-volume set (Leveraging WMI Scripting and Understanding WMI Scripting), and you'll have all the raw material you need, plus plenty of sample scripts you can adapt.
In some environments, of course, the extra functionality of tools such as MOM or Spotlight on Exchange is necessary. These tools can integrate and display a range of health and status parameters, and they give you much more sophisticated tools for monitoring server conditions and alerting you when something goes wrong. If you have a complex multiserver environment, or if your monitoring needs are driven by business requirements that force you to have more awareness of your messaging system's condition, these tools are probably a better choice than rolling your own. Having said that, judicious use of ESM's monitoring tools, combined with the performance-monitoring tools built into Windows, will give you much better visibility into the overall health and performance of your Exchange servers, helping you fix small problems before they turn into larger ones.
End of Article
Prev. page
1
[2]
next page -->
