on How to: send an email when a server reboots…including who and why!

So, I was told that this might make a good blog post, so thought I’d be a good person and share (because that’s the kind of person I am).

A bit of background: If you follow me on Twitter (and you totally should), over the last few days you may have seen me wearing my ranty pants due to some issues at work. Specifically, regarding a coworker rebooting production domain controllers during the middle of the day with no warning. No IM to the rest of the team to let us know. No email to inform us. Nothing.

Now, I can hear what you want to yell at me: “But if you’ve got your domain set up properly, it shouldn’t be an issue! With multiple domain controllers, there’s redundancy!” You’d be partially right. There is redundancy for the domain. But not for the apps that connect to the domain…and prefer to speak to a specific server (e.g. for LDAP binds). For the sake of getting past this, let’s say that in my environment I know what I’m talking about and rebooting a DC without any warning is bad juju…forgetting, for a moment, that rebooting any production server during business hours without warning is bad juju.

So, moving on. Because this particular coworker, even after being told to let people know, went and did the same thing again the following day – I decided that action needed to be taken. We needed something that would tell us when these servers were going down – sure, monitoring helps, but if the server goes down and comes back up so quickly that your monitoring doesn’t catch it, it makes it hard.

So I went hunting for something that would do what I was after…and I was able to find something that was close, and then kind of smooshed it into what I needed it to do.

So, here goes:

This is a fairly basic script, that I pared down from this one, from when I went hunting. The comments really tell the story – it gets the last EventiD 1074 entry in the System event log, parses that and turns it into individual variables. You put in your email address for To/From, punch in an SMTP server, and it spits out an email with the details of the EventID 1074. Pretty simple.

The following is the script I used. You can also download it here.

# Look for the last event with EventID 1074 in the System log. $EventInfo = Get-WinEvent -FilterHashtable @{logname='System'; id=1074} -MaxEvents 1 $EventInfo | ForEach-Object { $rv = New-Object PSObject | Select-Object Date, User, Action, Process, Reason, ReasonCode, Comment $rv.Date = $_.TimeCreated $rv.User = $_.Properties[6].Value $rv.Process = $_.Properties[0].Value $rv.Action = $_.Properties[4].Value $rv.Reason = $_.Properties[2].Value $rv.ReasonCode = $_.Properties[3].Value $rv.Comment = $_.Properties[5].Value $rv } # Set your email settings $From = <INSERT EMAIL ADDRESS HERE> $To = <INSERT EMAIL ADDRESS HERE> #$Cc = "" $Subject = $env:COMPUTERNAME + " has Rebooted" #My Email body contains custom properties that will differ from your system. $Body = "$env:COMPUTERNAME has rebooted at $($rv.Date) by $($rv.User) `r`nReason: $($rv.Reason) ($($rv.ReasonCode)) `r`nComment:$($rv.Comment) " $SMTPServer = <INSERT SMTP SERVER HERE> $SMTPPort = "25" # Send the email! Send-MailMessage -From $From -to $To -Subject $Subject -Body $Body -SmtpServer $SMTPServer

Now, all we need to do is put it into a scheduled task. The scheduled task I have set runs this at startup using the local SYSTEM account. Not sure if this is the best way (and if there is a better way, please share, remembering this was a quick throw-together I did in about half an hour!)

The following is the XML for the scheduled task, or you can download the .xml file here.

<?xml version="1.0" encoding="UTF-16"?> <Task version="1.4" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task"> <RegistrationInfo> <Date>2016-05-26T08:09:56.24079</Date> <Author>DOMAIN\USERNAME</Author> </RegistrationInfo> <Triggers> <BootTrigger> <Enabled>true</Enabled> </BootTrigger> </Triggers> <Principals> <Principal id="Author"> <UserId>S-1-5-18</UserId> <RunLevel>HighestAvailable</RunLevel> </Principal> </Principals> <Settings> <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy> <DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries> <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries> <AllowHardTerminate>true</AllowHardTerminate> <StartWhenAvailable>false</StartWhenAvailable> <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable> <IdleSettings> <StopOnIdleEnd>true</StopOnIdleEnd> <RestartOnIdle>false</RestartOnIdle> </IdleSettings> <AllowStartOnDemand>true</AllowStartOnDemand> <Enabled>true</Enabled> <Hidden>false</Hidden> <RunOnlyIfIdle>false</RunOnlyIfIdle> <DisallowStartOnRemoteAppSession>false</DisallowStartOnRemoteAppSession> <UseUnifiedSchedulingEngine>false</UseUnifiedSchedulingEngine> <WakeToRun>false</WakeToRun> <ExecutionTimeLimit>PT10M</ExecutionTimeLimit> <Priority>7</Priority> </Settings> <Actions Context="Author"> <Exec> <Command>powershell.exe</Command> <Arguments><LOCATION OF SCRIPT></Arguments> </Exec> </Actions> </Task>

When it runs at startup (or manually, if you want it to!) the following is what you’ll get:

So that’s it – how to make sure you get an email when a critical server reboots and get the information you need to work out who and why!