Activate those event logs, pardner!
Event logs are great tools for keeping track of your system. But they have one liability: You have to go look at them to see if anything important has happened. Just about every Windows administrator I know has a story about puzzling for hours over some strange system behavior and finally remembering to look in the event logs, in which the answer was evident. But suppose certain kinds of events are sufficiently important to you that you don't want to have to look at event logs to deal with them. Wouldn't it be nice to be able to configure your system to immediately and automatically respond to certain events?
You can accomplish such configuration with an event trigger. An event trigger essentially says to your system, "When this event happens, run this program." For example, suppose you're on the trail of a hacker and want to be informed every time a logon failure occurs. You could create an event trigger to use Net Send to deliver you a pop-up message or to use a program such as Blat to send you an email message from a command line. But how do you create an event trigger? You use eventtriggers.exe, which is included in Windows Server 2003 and Windows XP.
Eventtriggers.exe has a fairly complex set of parameters. The top-level parameters are /create, /delete, and /query, which let you create a trigger (triggers remain in the system until you remove them, rather than firing once and disappearing), delete a trigger, and list the triggers in the system, respectively. Simplified, the syntax for creating a trigger is
Eventidnumber is the number that tells which specific event happened—for example, 680 for an account logon, or 1054 when Group Policy can't find a domain controller (DC) to obtain your Group Policy files. Triggername is a label that identifies the trigger—you need this label to read the event trigger logs ("Which trigger did that?") or to delete a trigger. Actiontotake is the command that you want your system to execute when the particular event ID occurs—either a command-line command or the name of a batch file to run.
Before diving deeper into Eventtriggers' syntax—it has many parameters that you might find useful—let's try out an example. One event ID that's easy to generate for our testing is event ID 64002. Windows File Protection generates event ID 64002 when you delete one of the .exe, .dll, .sys, or .ocx files that ship with the OS in the \system32 directory. To demonstrate the generation of this event ID, just type
del C:\windows\system32\sol.exe
on a Windows 2003 or XP box. (If you've upgraded your system from an earlier version of Windows NT, you would use \winnt instead of \windows.) Now, when you look in the System log, you'll see event ID 64002. Next, what shall we tell the system to use as an action? If you have the Messenger service enabled on your system, you can use the Net Send command. For example, assuming your username is jack123,
net send jack123 Something's deleting system files!
would pop up a gray box on your desktop that states Something's deleting system files!
But we need one more piece: a security context. By default, Eventtriggers will run the Net Send command (or any other command) under the System account, but System can't effectively run some commands, including Net Send. So we can add two more parameters—/ru and /rp—to give Eventtriggers a user account and password to use when running Net Send. If your user account is jack123 and your password is swordfish, you could use the following command to create a new event trigger named sysalert:
Of course, this command only informs you that the deletion is occurring. You'll have to find the miscreant to stop it.
In the space I have left, I can share a couple more useful Eventtrigger commands. To list your event triggers, type
eventtriggers /query /v
To delete all your event triggers, type
eventtrigger /delete /tid *
I'll share more Eventtriggers commands next month.