Fingering More Eventtriggers

In "Pulling the Event Trigger" (December 2004, InstantDoc ID 44431), I introduced event triggers, a feature in Windows Server 2003, Windows XP, and Windows 2000 that lets you configure the OS to automatically run specified programs when certain event IDs occur. This month, let's finish our discussion of eventtriggers.exe with a look at further switch options.

Syntax Specifics
First, let's get specific about the /create syntax. Following is the proper Eventtriggers syntax to tell the OS to watch for any attempts to delete protected system files (which produces event ID 64002) and, if such an attempt happens, to send a pop-up message to a user named Jack whose password is swordfish:

eventtriggers /create /tr sysattack /eid 64002
   /ru jack /rp swordfish /tk "net send jack the
   system is under attack!"

But how can you specify Jack's account name? Unlike far too many Windows utilities, Eventtriggers recognizes both the domainname\username and username@domainname syntaxes. The bigfirm\jack and jack@bigfirm.biz formats work equally well.

How do you find out what event triggers your system has in place? Typing

eventtriggers /query

yields a simple list of the trigger IDs—numbers that identify each trigger's name and the command to execute if the trigger fires. You can add the /s systemname, /u username, and /p password options to access a remote system's event triggers list. Adding the /v (verbose) switch provides further details about the triggers. You can also use the /fo option if you want to format the output as a simple table (the default output format), a list, or a comma-separated value (CSV) file (using the table, list, and csv options, respectively). For example, to dump a verbose list of triggers as a CSV file, type

eventtriggers /query /fo csv /v

You'll need the trigger ID value to delete a trigger if you no longer want it on your system. To delete a trigger, you use the command

eventtriggers /delete /tid <triggerID>

To delete all triggers, you can use an asterisk (*). Or, you can stack several triggers you want to eliminate, as follows:

eventtriggers /delete /tid 1 /tid 5

Trigger Log
Before you get an itchy trigger finger, I'll warn you that event triggers aren't wonderful about telling you what they're doing. Debugging them can therefore be a bit mysterious. Windows offers one bit of help: CmdTriggerConsumer.log. Located in \windows\system32\wbem\logs, this ASCII text file records sparse information whenever someone creates or deletes a trigger, or when a trigger fails to work. In this log, you might see an entry such as the following:

Wed, Jul 07 2004 12:10:09 PM
TriggerName = sysattack
TriggerID = 1
Action = Failed to Trigger

Notice that the entry doesn't tell you why the trigger failed—only that it did. But such information can still be useful. As I worked with the examples for this two-part series of articles, I tried creating triggers that would run a Net Send command, but I never saw any of the pop-up windows that Net Send usually generates. I tested the syntax by typing the Net Send command directly from the command line, and it worked fine. I wondered whether the trigger was working. Or perhaps I'd messed up some aspect of the Eventtriggers syntax. Checking the log confirmed that the event had occurred, but the trigger had attempted an action and failed. Armed with that information, I tried adding the /ru and /rp options, forcing Eventtriggers to use my credentials rather than the LocalSystem account's credentials. Problem solved.

Homegrown Help
Many effective—but expensive—monitoring applications on the market can alert you or even proactively contact you when certain events happen on your system. But if you can't abide the high prices of such solutions, try using Eventtriggers to stitch together some nice homegrown help.

End of Article