In server 2008, it’s quite easy to attach a task to an event. In EventViewer, simply right-click on the event and choose Attach Task to This Event. This is fine and dandy but sometimes, we want a little more granular control over when to actually fire the task; e.g., I typically want to only notify myself via email of failed RDP logons, not ALL failed logons.
It’s a little more complicated to get only the events you want based on some details inside the actual event – the Event Data.
Note: In Server 2008 the EventID for a Successful Logon is 4624 and for a Failed Logon is 4625. There are multiple Logon Types and you can reference them at this link from MSDN and adapt this guide to your liking. Look at the Logon Type section specifically.
These are the two XPath filters I’ll be working with and I will show you how to create 2 tasks based on 2 separate events:
1. Failed RDP Logon
2. Successful RDP Logon
XML for Failed RDP Logon
Note: After doing some testing, it seems that LogonType 10 isn’t working for notification but LogonType 3 is. I’m still looking at why this is the case since this is RDP logon I’m testing.
<Query Id="0" Path="Security">
<Select Path="Security">*[System[(EventID=4625)]] and *[EventData[Data[@Name='LogonType'] and (Data=10)]]</Select>
XML for Successful RDP Logon
<Query Id="0" Path="Security">
<Select Path="Security">*[System[(EventID=4624)]] and *[EventData[Data[@Name='LogonType'] and (Data=10)]]</Select>
Repeat all the steps from 1. Failed RDP Logon, simply replacing the XML EventID with 4624.
Manage Event Viewer Tasks
You can see all your Event Viewer Tasks by launching Task Scheduler (Start -> taskschd.msc [ENTER]) and choosing the Event Viewer Tasks folder.
Hopefully this helps anyone out there that has been wondering how to do this. Got any more tips? Let me know. I’d be interested to know if you can specify variables in the email output – like other XPath variables that could be set or something. Maybe even a specific event tag so that instead of directly emailing, you could write a short script that runs and will get the full details (Event Data) of the event and then embed it in an email.
I have found (Oh, glorious Google: Ref 1, Ref 2) how to reference Event Data in the emails. This makes me excited and now I’m cooking up commands also for dynamically adding IPs to RDP firewall for this case.
So, to be able to reference a variable from the Event Data, you need to add a ValueQueries element (MSDN link) to your Task. The easiest way to do this is to export your task as XML and open it with notepad to edit it. First, let’s look at some of the data options available to use as variables. To get these, I like to find an event in the event viewer and look at the XML and look at the Data elements.
Let’s go back to what I was wanting to do originally – notify via email when a failed RDP logon occurs. Now, I not only want to just send myself an email but I want to include some extra information. In this case, I want to include the IpAddress as well as the TargetUserName. This will tell me which IP address the logon came from as well as what user name the remote system tried to use. Awesome!
So, fire up task scheduler (Start -> taskschd.msc [ENTER]) and navigate to the event viewer tasks item in the left pane. Then, right-click the task we created earlier (Failed RDP Logon) and choose Export.
Save it somewhere convenient and then right-click and choose Edit (or open with notepad).
We need to add a ValueQueries element in the EventTrigger element.
You will want to add the ValueQueries element in the EventTrigger element. Of course if you aren’t following what I’m doing, change them to something you’d rather see from your own available event data values.
Now that we have setup the variables, let’s add them to our email message. This can be done from in this exported task easily. Scroll to the bottom and look for the following block of code:
In that, modify your Body element to reflect your variables. Note: Variables are CAsE-SenSiTive!
So in conclusion there are some really cool “tricks” we can do here to help monitor our systems. Another cool thing would be to, instead of email notification, simply take the $(IpAddress) and pass it to a command such as, say,: