SNMP and MOM: Bug in the script listed in KB 555455

I know there are already several articles and posts about SNMP and MOM, but recently I have been working with SNMP feeds from Conceivium MobileMonitor to MOM and I was/am getting frustrated.

 

Conceivium outlines how to implement the script MSFT provided via a KB article so that your MOM environment can start to get SNMP alerts from the Conceivium agents.  However, the script MSFT provides is very weak and has a bug in it.  Conceivium does a pretty good job of getting you started monitoring via MOM, but they need to add a few things to their documentation so that people can make use of the SNMP data.  I plan on providing them some documentation that they can use so that other’s can benefit.  I will document what I found here so that you can all benefit from it.  I would also like to thank in advance Pete Zerger, John Hann, and Marcus Oh for dealing with my spam, questions, and random rants.  I should also thank my MSFT contacts Justin Incarnato, Kepp Andrews, Jason Johnson, and Kent Yoo for putting up with me as well.

 

I have not completed the document as of yet, but I wanted to help those of you who might be running into an issue with alert levels via SNMP traps fed into MOM.

 

The script listed in the MSFT MOM KB article is this:

 

Set objEvent = ScriptContext.Event
Set objAlert = ScriptContext.CreateAlert()
 
objAlertLevel = 50
objAlert.AlertSource = "SNMP"
objAlert.Name = "SNMP Alert"
objAlert.Description = objEvent.Message
objAlert.Computer = Replace(objEvent.EventParameter(11),".","-")
objAlert.ComputerDomain = "SNMP"
 
ScriptContext.Submit objAlert

 

I kept changing the value from 50 to something else, but it never changed the alerts that were raised in the console.  This is because the item for objAlertLevel is incorrect.  It should be:

 

objAlert.AlertLevel

 

If you change it to that, then you can set the level to the right level of alert that you want.  If you do nothing, then the entire time you will get Critical Errors.

 

As soon as I finish my document on some SNMP trap tips, I will publish it.

Exchange Management Pack: Script error for Mapi Logon and more

I recently was updating some documentation on our MOM implementation when I found an issue in the Exchange Management Pack.  From what I can tell this issue existed in the past two management packs, maybe even others.  However, I will outline what you need to do in order to correct the issue.

 

I wouldn’t say this is a CRITICAL problem; However, it really shouldn’t have been missed by the QA team because it is essential for companies who may have a large implementation of Exchange and or add/remove Exchange servers often from their environments.

 

To make changes to this script, you have to first locate the rule that executes it:

 

Microsoft Exchange Server>Exchange 2003>Availability and State Monitoring>MAPI Logon Check and Availability Reporting

Check mailbox store availability – MAPI logon test.

This is the rule that launches the script with mistakes in it.  Go to the response tab and edit the script.  Copy the script code into an external editor or notepad and you will notice the following mistakes:

 

// Exchange MOM 59987 inform Attempting to publish Exchange Management Pack data
// Exchange MOM 59988 inform Please run Exchange Management Pack Configuration Utility

// Exchange MOM  59990 error Cannot measure server availability: error verifying pub key

 

The above information is taken from the description of the script and the events that it will generate.  Now I thought maybe the author just mistyped the description, but if you search the script for these events you will find them.  If you create a event view in MOM you will also find these events (if the rules are enabled and you have Exchange in your environment).  Mostly you will probably only find the event asking you to run the Exchange configuration wizard.

 

Why are these event ids important?  Because this script generates those events and there are other rules in the Exchange management pack that look for these events (without the 5 in front of the 9’s).

 

So simply remove the 5’s and then save the script.  This should correct the issue.

 

Another rule that was acting odd is this one:

 

Microsoft Exchange Server>Exchange 2003>Availability and State Monitoring>MAPI Logon Check and Availability Reporting

Test mailbox residing on the wrong server

I enabled this rule (had disabled it before) and I got several alerts that were raised by this rule.  However, the description was All logins were successful.  I was confused, so I looked at the rule and noticed it had a regular expression for the event id’s.  I modified it so that the only event id it was looking for was 9996 (which is the event that will tell you that a MOM mailbox is residing on the wrong server).  After I changed it, I was able to see the few servers that had this condition.  So you might want to check this rule and make the same changes.

 

Finally, I was looking at some of the default public views for Exchange and found one that listed nothing because the criteria is incorrect.  The view is here:

 

Public Views>Microsoft Exchange Server>Exchange 2003>Server Configuration and Security>Configuration Information

Exchange Servers not in a cluster

I attached a screen shot of the properties of this view (momview).  I didn’t dive into trying to fix this, but I assume since it is looking for 9002 that this is just the Exchange configuration that gets dumped from the script that runs daily.  If you create a computer group that has non clustered Exchange servers, then you can change the criteria so that only the 9002 events from that computer group show up here.  My point is that the view is broken.  I don’t think it really adds that much value, but it’s worth pointing out that it doesn’t work and should probably be removed or fixed.