The array itself doesn't send the email. It does a broadcast and the system that has MDSM installed on it would monitor for this broadcast and then turn around and send the email.

On Windows servers the MDSM install installs the Modular Disk Storage Manager Event Monitor service, but on Linux it uses the native sendmail capabilities.

This email is SMTP (so no authentication). Check which system is set up the monitor for the broadcasts and turn the broadcast into an email. Then check with your email admin to see if that system is on the list of systems that is allowed to send emails using SMTP (no authentication means it could be abused by a spam-bot, so most mail admins block smtp and make an exceptions list for devices/systems that are 'legit' to send smtp messages).

Just goes to show how just when you think you know it all,  you always find out you don't....

I had no idea that is how it worked.   Makes it imparitive you have an MSDM up and running and available to the array at all times.   I will have to review that specifically in all our setups now for sure.

Thanks a million,

John

I do need to clarify that the SMmonitor service applies to both Windows and Linux.

The SMmonitor is installed with both the All and Management Station installation selections and during install there is a option to disable this service from running. The default selection is for it to auto-start and typically the option should not be changed so that the SMmonitor service is always running.

If the SMmonitor service is running MDSM does not need to be up and running, that's the explicit purpose of the SMmonitor service. The SMmonitor keeps track of all arrays that have been configured for monitoring via MDSM and will send out a SMTP or SNMP alert based on the alert configuration. There are no options or interface for the SMmonitor service as it reads the alert information from the configuration file that MDSM creates.

I hope this clears up the relationship between MDSM and the SMmonitor and how alerts are configured and generated, if not please ask!

For the original post the net is to ensure that SMmonitor is running.

Just to clarify a little further...

On windows O/S, the only way to get the SMmonitor service up and running is to install MSDM right?

You have to install the management part of MDSM (the 'Typical' option installs the management and host parts) to get SMmonitor.

Interesting replies, thanks everybody.

So, in summary, in practice you have to install and run the Storage Manager plus SMmonitor on the system where you want SMmonitor to run, in order to configure the monitor.  Then, once you exit the Storage Manager, SMmonitor keeps running as a service and - supposing it is set to start on boot - needs no further configuration even after reboot.   This does raise some issues about duplicate messages in an HA system, where at least two nodes are involved, but no more so than for other services.

SMmonitor was installed, but I guess what happened was that after a reboot of the simple PC which was the management station it was not running at the critical time when the disk failed.

In short your summary is accurate. 

Detail is that SMmontor is always installed with MDSM,  it's optionally disabled from auto-starting. Note that test SMTP or SNMP alerts are sent directly by MDSM, not the SMmonitor, but as pointed out SMmonitor does read the exact same configuration information.

Regarding duplicate messages, typically one separate server or client is dedicated as a management station and the host servers are only supporting the application and I/O to the storage array. That way the management station can be on a completely different network if so required. MDSM itself is not typically installed on every host server.