- Solution overview
- Installation and configuration
- The SMTP service
- Set registry keys
- Import the Management Pack
- Create an override Management Pack
- Configure mail match patterns for explicit monitors
- Mail routing to receive alert email
- Management Pack components
- Discoveries
- Monitors
- MailMonitoritem Timer Reset
- Rules
- Views
- Conclusion
- Monitoring Microsoft 365 with SCOM and the NiCE Active 365 Management Pack - Tue, Feb 7 2023
- SCOM.Addons.MailIn: Monitor anything that can send email with SCOM - Mon, May 25 2020
- Display a user’s logged-on computer in Active Directory Users and Computers (ADUC) - Mon, Jan 21 2019
Solution overview
The standard Windows SMTP service is used to receive emails. Incoming emails are stored as EML files. PowerShell scripts within the Management Pack (MP) parse the EML files, extract the information and return them to custom SCOM modules. Afterwards, the files are moved to an archive folder.
Without customization, each email is taken by an SCOM rule and converted into an alert with a severity of "warning."
When filter patterns for subject, sender, body, or source SMTP server are defined in an XML file, individual objects in SCOM "MailItems" will be generated. Two different monitors check incoming email against "MailItems" and change the health state when they find a match. This allows for individual objects for air conditioners, UPS, or banking applications, and having the state changed to Critical if an email matching the filter comes in.
Installation and configuration
The following steps are required on one Windows Server 2012 or higher that is monitored via SCOM agent:
- Install and configure the SMTP service
- Set registry keys
- Import the Management Pack
- Create an override Management Pack
- Optional
- Add mail match patterns to the XML configuration file for object creation that are targeted by monitors
- Configure mail routing to receive emails by corporate email address for the SCOM server
The SMTP service
Start the Windows Server Manager and add IIS and IIS 6 Management Tools.
In the features section, add SMTP Server Tools and ODBC Logging.
After installation, firstly set the SMTP service the listing IP address.
Second, set relay restrictions to the own IP addresses, localhost, and your internal mail servers (e.g. Exchange hub transport servers).
Set registry keys
Registry keys store basic information about the SMTP service. Paste the text in the yellow box into Notepad and save it as smtpmp.reg:
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\ABCIT\SCOMAddonsMailIn] "XMLConfigFilePath"="C:\\Temp\\scom.Addons.MailIn.MonitorItemList.xml" "EmlDirectory"="C:\\inetpub\\mailroot\\Drop" "EmlArchive"="C:\\Temp\\MailArchive" "NoOfLinesFromTop"="100"
- XMLConfigFilePath
- Location of the XML file that holds information about the custom mailmonitor patterns.
- EmlDirectory
- Path on which the SMTP service stores the emails. The value in the yellow box is the default location.
- EmlArchive
- Storage folder for emails that have already been processed by A rule will automatically delete old files.
- NoOfLinesFromTop
- Specifies how many lines of the email body are read by SCOM.
Double-click the smtpmp.reg file to import the settings. Confirm the upcoming dialog box by clicking Yes.
If the defaults are kept, the registry should look like this:
Import the Management Pack
In the SCOM Console, select the Administration section, select Management Packs, and click Import Management Packs.
Add the SCOM.Addons.MailIn.mpb file from your downloads folder and import it.
Proceed with the wizard by confirming all default settings.
Create an override Management Pack
In Administration > Management Packs, click Create and name the new management pack SCOM.Addons.MailIn.Overrides to store customizations.
Proceed with the wizard by confirming all default settings.
Configure mail match patterns for explicit monitors
Create a file named SCOM.Addons.MailIn.MonitorItemList.xml, store it in C:\Temp, for example, and configure the desired mail matching patterns.
A part of the text is enough for the match pattern. For example:
- Original subject: NYHKFW01 _IP:_10.25.10.21_changed_state_to_Down_on_Saturday,_May_9,_2020
- Match pattern in XML: changed_state_to_Down
- Original MailFrom: "APM-C-Test@abc.de"_<APM-C-Test@abc.de>
- Match pattern in XML: APM-C-Test@abc.de
The patterns are used to create objects. Monitors will then be triggered if an email that matches the description arrives.
At least two items must match to let SCOM create the object (MailMonitor Item).
The logic will try to match any specified information. If more values are listed in the XML, it will be reflected in more concrete objects and matching. If fewer values are listed in the XML, the matching will be less accurate.
The minimum two-item match means, for example:
MailFrom and MailSubject matches
MailSourceServer and MailSubject matches
MailFrom, MailSubject, MailSourceServer matches
The XML file would look like this:
<MailInMonitorList> <MailMonitorItem> <UniqueTitle>P360 APM Issue</UniqueTitle> <Description>Application errors in TEST system</Description> <MailFrom>APM-C@yourcompany.abc</MailFrom> <MailSubject></MailSubject> <MailBody></MailBody> <MailSourceServer>Linux05</MailSourceServer> <SCOMAlertResetType>Manual</SCOMAlertResetType> <SCOMAlertResetTimeInSeconds></SCOMAlertResetTimeInSeconds> </MailMonitorItem> <MailMonitorItem> <UniqueTitle>SAP Auto Job Error</UniqueTitle> <Description>Auto booking table issue</Description> <MailFrom>NightJobber</MailFrom> <MailSubject>ZLAS_STATUS</MailSubject> <MailBody></MailBody> <MailSourceServer>SAPAppSrv05</MailSourceServer> <SCOMAlertResetType>Timer</SCOMAlertResetType> <SCOMAlertResetTimeInSeconds>7200</SCOMAlertResetTimeInSeconds> </MailMonitorItem> </MailInMonitorList>
The first and last lines are needed to indicate the start and end of the object list.
- UniqueTitle*
- The key property; must be unique. It should be short and descriptive.
- Description
- Only for usability, to store information for those who check in SCOM
- MailFrom*
- Either the text of the From field or the Sender email address
- MailSubject*
- Text that is found in the mail subject
- MailBody
- Text that may be found in the body
- MailSourceServer
- Server or device that sends the email to SCOM
- SCOMAlertResetType
- Set to Timer or Manual to determine how this object should be monitored.
- Timer: The monitor will be forced to reset after the threshold (SCOMAlertResetTimeInSeconds) is reached. The object will be healthy again.
- Manual: The monitor keeps the object in the Error or Warning state until a SCOM admin resets it.
- Set to Timer or Manual to determine how this object should be monitored.
SCOMAlertResetTimeInSeconds applies when a timer is specified in SCOMAlertResetType. The value must be greater than 900 (15 minutes) to avoid exhausting the SCOM resource.
(*) Must contain a value; if it does not, the item will be ignored.
Mail routing to receive alert email
After completing the steps above, SCOM can receive email and create alerts only if the Windows Server where the SMTP service was installed, is specified as an SMTP server for the sending device (server, application, etc.). For increased flexibility, mail routing can be customized so that only an email address for the SCOM servers is required.
Example:
- Create a DNS Alias (CName): yourdomain.com, which points to the Windows Server with the installed SMTP service
- In Exchange, use SendConnector: to specify that scomalert.yourdomain.com will be sent to the SmartHost
- In the SMTP Service: add alias domains to receive email for scomalert.yourdomain.com.
Now you can use anyText@scomalert.yourdomain.com on your sender, and the mail routing will ensure that the messages are delivered to SCOM.
Management Pack components
Discoveries
Everything in SCOM that has a health state is an object. Instead of checking all Windows computers to see whether those files exist, we define a dedicated computer class.
MailMonitorItem ManualReset
Items specified in SCOM.Addons.MailIn.MonitorItemList.xml that have the SCOMAlertResetType set as Manual.
MailMonitorItem TimerReset
Items specified in SCOM.Addons.MailIn.MonitorItemList.xml that have the SCOMAlertResetType set as Timer.
Monitoring Server
The registry keys mentioned in Initial setup/Set registry keys are used to set this Windows Server as an email server and target for discoveries, rules, and monitors.
Monitors
Monitors are for finding out which health state an object has. An object can be Healthy (green), in Warning (yellow), or Critical (red).
MailMonitor Item
No direct monitor. Appears here because it is the base class of ManualReset and TimerReset MailMonitor Items.
MailMonitorItem Manual Reset
Reacts if an incoming email matches the configured pattern in the XML file.
The SCOM administrator needs to reset this monitor manually.
By default, this monitor runs every 5 minutes.
MailMonitoritem Timer Reset
Raises an alert if an incoming email matches the configured pattern in the XML file.
After the specified threshold in the XML file is reached, the monitor is reset when it is checked the next time. In other words, the threshold is only checked when the monitor runs, which is every 5 minutes by default.
Monitoring Server
Monitors the Windows SMTP Service
Note: XML file = SCOM.Addons.MailIn.MonitorItemList.xml
Rules
In this Management Pack, rules perform alerting and cleanup jobs to help you avoid manual maintenance. The main parameters of the rules can be changed via override.
MailIn Generic CleanEmlArchive Rule
After an email is processed, the EML message will be moved to an archive folder, which by default is C:\Temp\EmlArchive. All EML files older than 720 hours (30 days) will be deleted.
MailIn Generic Alert Rule
If an incoming email does not match the pattern configured in the XML file, a warning alert will be created. If preferred, the warning can be changed to Critical, and the check interval can be checked as well.
MailIn Close Alerts Rule
To reduce the manual effort of closing alerts triggered by the rule above, this rule will perform closure after a customizable value.
Note: XML file = SCOM.Addons.MailIn.MonitorItemList.xml
Views
State views make all discovered objects and their health state visible. The Closed Alerts subfolder helps to check information about last closures.
Subscribe to 4sysops newsletter!
Conclusion
You can download the management pack with the *.mpb or *.xml extensions from GitHub. I published the entire software under the GNU General Public License on GitHub. Feel free to use it without cost or obligation. The software is provided "as is" without express or implied warranty.
Read the latest IT news and community updates!
Join our IT community and read articles without ads!
Do you want to write for 4sysops? We are looking for new authors.
thanks
Hello there!
Thank you for your work, but we have a problem with isolating mails from a san.
The san is trying to send an e-mail which trying the discovery some hosts in VMware, and the e-mail is kind of false postive, and inside the body of the mail is ‘Critical’ word.
And we have added the word critical so it can alarm in this case, we tried to have another mailitem for the discovery failed and overrided from SCOM, and we added this mailitem first, so the xml read it from above.
Now we get two alarms, one as a critical and one as information with two different objects in the alarm.
And i want to see if there is any option that i missed to ignore a type of alarms that we want to override.
Well, i figured that out, the field does supports regex, that’s what solved the problem