In case anyone tries to do this, I thought I'd give an update here for posterity. Below is the body of a ticket created from an event log alert, which is fine for human processing. I'm using ServiceDesk and I want to be able to "automate" certain types of common events. But Before I can do that, I need to accurately know the EventID, the Log that generated the event, the type, etc. So I've created several custom fields, SourceType, EventLog, EventLogSource, EventID, EventLogType, and EventLogCategory.

----EXAMPLE TICKET SUMMARY AND DESCRIPTION-----

Summary: [some-srv.some.place] System log generated Warning Event 2094

Description: System log generated Warning Event 2094 on some-srv.some.place

For more information see www.eventid.net/display.asp Administrator

Log: System

Type: Warning

Event: 2094

Agent Time: 2011-11-27 23:54:03Z

Event Time: 04:51:22 AM 28-Nov-2011 UTC

Source: Server Administrator

Category: Storage Service

Username: N/A

Computer: SOME-SRV

Description: Predictive Failure reported: Physical Disk 0:4 Controller 0, Connector 0

---------------------------------------

Using the example, I'd like to populate my custom fields as follows:

SourceType: Event Log

EventLog: System

EventLogSource: Server Administrator

EventID: 2094

EventLogType: Warning

EventLogCategory: Storage Service

First, it's important to understand that some of the information you need is only available in the Ticket Mapper procedure. This is a "pre-precessing" procedure that helps to direct which service desk to send the ticket. So, if you had a different service desk for Event Log alerts vs Agent Off Line alerts, this is where you could make that determination. It's also the only place that you can access the original SourceType (not my Custom Field) as well as 3 variable/value pairs called SourceType1,2&3 and their corresponding SourceValue1,2,&3. These change with each type of ticket. For instance, SourceType3/SourceValue3 is blank/empty for Agent Off Line alert (probably others too).

SourceType is equal to whatever "caused" the ticket to be created - ie: Event Log, Log Parser Monitor, Counter, etc. So that seems to be an easy value to populate. The rest get tougher. But those variables can help a little.

Here is an example of these variables when an Event Log ticket is created and where you can find more info about the values.

SourceType is Event Log

SourceTag1: AgentGuid

SourceTag2: AlertRegistrationId

SourceTag3: LogType

SourceValue1: xxxxxxxxxxxx (actual GUID removed)

SourceValue2: 104 ---> to get real name checkout the dbo.alertRegistration table

SourceValue3: 1380569194 --> to find out which Log this is checkout dbo.eventLogType table

So SourceValue3 maps to the name of the Event Log. So I call a SQL from my mapper procedure like this: select displayName from eventLogType where EventLogTypeId=[$SourceValue3$] and set it to a variable and then set that variable to my custom Field "EventLog."

SourceValue2 seems to be a repeat of the SourceType. However, when I look through the dbo.alertRegistration table it seems there are a lot of possible values and SourceType might just be a "dumbed down" version. So, if SourceTag2 = "AlertRegistrionId" I go ahead and get the real name from dbo.alertRegistration table for the SourceValue2 (ie: 104) and take that over SourceType because it more be a more detailed Event Log name.

Next, I have a very simple set of If/Else-If type logic to look for the EventLogType. There are only a handful of them (Information, Warning, Error, Success Audit, Failure Audit, Critical, Verbose), so I can safely look for each by checking the body for the existence of each (if exists - Log: Information, Log: Warning, etc). I can then set the value of EventLogType based on which one matches.

So at this point, I've got this much of my data filled in:

SourceType: Event Log

EventLog: System

EventLogType: Warning

Now I really want the EventID because without it, I can't really do much else. Luckily, the Summary of the ticket contains the Event ID in a consistent format. It's always the last thing in the summary. So, after a bit of googling, I came up with a very simple VBScript to parse the Summary and return the last element - which is the EventID.

outputArray  = split(wscript.Arguments(0))

wscript.echo outputArray(uBound(outputArray))

I saved this as VBParseTicketSummary.vbs and uploaded to my K server SharedFiles location.

Now at this point, I can't do what I want from inside the Ticket Mapper procedure. So I move onto the New Ticket Created procedure, which is the next thing that is called in the chain (once the mapper maps it to the Service Desk that I am using). But I really don't want to do any heavy lifting in here. So I make a sub-procedure for handling Event Logs. From the New Ticket Created proc I check if SourceType = "Event Log" and call the sub-procedure for Event Logs. This format will work nicely because as I expand into other monitors I can create a seperate handler for each in the sub-procs.

So in this proc I execute a command shell like this: cscript /nologo D:\Kaseya\WebPages\ManagedFiles\VSASharedFiles\VBParseTicketSummary.vbs "[$Summary$]" and save to a variable. Then I save that variable to my customField "EventID" and I've got pretty much everything I need to identify the ticket for automated processing.

I'd still really like to get the Source. I don't think the Category will be all that important for figuring out how to automatically handle these but it would be nice for reporting purposes maybe. I will likely try to get these last 2 variables through a combination of brute force logic and vbscripting. If I figure out how to do it, I'll be sure to post it here.  

Thanks for updating this ticket with your progress!

shankwc If you are still using KSD I would be interested to hear how you are currently using the ticket mapping procedure and output variables created by ExecuteSqlQuery.