No Shoes, No Script, No Service
Never miss another e-mail notification again.
People are always asking how to get e-mail notifications sent to them when
a service fails. You could invest in any number of server monitoring solutions,
but let's see what we can do for a whole lot less.
I've created a Windows Script File that lets you run a VBScript as if it were
a command-line utility. You can configure it to send you an e-mail notification
when a service fails. The first caveat is that if any key service associated
with sending an SMTP message fails, the script won't do you any good.
Download the script -- SendMailAlert.wsf -- from www.jdhitsolutions.com/scripts.
Then copy it to every server upon which you plan to use the script. You can
run it from a network share, but you might run into security warnings about
running scripts from a remote site.
For the sake of discussion, I'll assume a local install to C:\Scripts. Open
a command prompt and change to C:\Scripts. Type cscript
SendmailAlert.wsf /? and you'll get help. When you execute the script,
you'll need to specify:
- the service name
- one or more e-mail addresses to which the alert will be sent, separated
- an e-mail address for the "From" field
- the name of the SMTP server that will deliver the mail message.
There's a debug feature included with the /trace parameter. When you use this
parameter, it opens an IE window to display trace messages.
To configure your server, you'll need to modify the Recovery tab for every
service you've deemed mission critical. Open the Services management console,
find the service and double-click to open, and then select the Recovery tab.
This lets you specify which actions to take when a service fails.
Select which failure instance you want to use and pick "Run a Program"
from the drop down list. Enter CSCRIPT.EXE as the
program name. For command-line parameters, enter in the script name and your
parameters using this format:
path-to-script\SendMailAlert.wsf /svc:ServiceName /to:firstname.lastname@example.org/from:Alert@company.com
Even though you're configuring a specific server you need to specify the service
name. There doesn't seem to be a way to dynamically pull the service name. If
the name has spaces, enclose it in quotation marks. You must also define e-mail
addresses and the name of your SMTP server. Let's assume you configured the
Spooler service on server PRINT02 to use this script. You might have a command-line
parameter entry like this:
c:\scripts\SendMailAlert.wsf /svc:Spooler /to:email@example.com /from:MrRoboto@company.com
When delivered, the e-mail message will have a subject line like this: "Alert!
SPOOLER service on FILE02."
The message body will be: "This message is to inform you that the SPOOLER
service has stopped on PRINT02 at approximately 4/8/2007 11:25:26 PM."
You'll have to edit the script if you want to modify the subject line or body.
The script only executes when the service fails.
To test this process on a non-production server or at your desktop, configure
the Spooler service to use the script and send the alert to yourself. Open Task
Manager and kill the Spooler process. You should then receive an e-mail alert.
Now, for the rest of the caveats: First, depending on your network and mail
server, you may need to configure it to allow message relaying, especially if
you need to send a message to an external address. You can manually execute
the script from the command line at any time, as long as you provide all the
parameters. Also, the script doesn't restart the service, although it can be
rewritten to do so. My assumption was that if a mission-critical service failed,
you'd want to assess the situation and start the service manually. Finally,
if there's any sort of network connectivity problem between the monitored server
and the SMTP server, the e-mail alert will fail. Despite this limitation, I
hope you still find this a viable and affordable solution.
Jeffery Hicks is a Microsoft MVP in Windows PowerShell, Microsoft Certified Trainer and an IT veteran with over 20 years of experience, much of it spent as an IT consultant specializing in Microsoft server technologies with an emphasis in automation and efficiency. He works today as an independent author, trainer and consultant. Jeff writes the popular Prof. PowerShell column for MPCMag.com and is a regular contributor to the Petri IT Knowledgebase and 4SysOps. If he isn't writing, then he's most likely recording training videos for companies like TrainSignal or hanging out in the forums at PowerShell.org.
Jeff's latest books are Learn PowerShell 3 in a Month of Lunches, Learn PowerShell Toolmaking in a Month of Lunches and PowerShell in Depth: An Administrators Guide.
You can keep up with Jeff at his blog http://jdhitsolutions.com/blog, on Twitter at twitter.com/jeffhicks and on Google Plus (http:/gplus.to/JeffHicks)