Kaseya Community

How I Pass Variables from SD to Agent Procedures

  • Something that has always bothered me about Service Desk was not being able to pass a variable from a SD ticket to a agent procedure.  Hopefully I will give you a idea on how I accomplished this and how we use it - and would like to hear ( read ) any ideas or other ways you have accomplished the same thing.  I don't plan on giving out all the code ( if you need help ask though ) - but hopefully set you off in the right direction if you choose to do so.  Hopefully you guys can follow this, but if not feel free to ask questions!

    First some background..

    We use Kaseya and Connectwise - using the email connector.  Prior to SD - A ticket is generated in Kaseya and it sent a email to our Connectwise board.  We had email parsing rules in place in Connectwise to decide where the ticket went.  This worked OK but I was always annoyed at "Windows Service Failure" tickets..  These tickets told me it stopped, but not weather Kaseya was able to restart the service or not..  We also had just about 0 control over any type of real automation based on variables..  Then came service desk..

    After playing with service desk - and rebuilding my desk - a lot - I finally got the hang of it and what I wanted to use it for and what it could do for us..   Based on variables, I can send a email here or close the ticket and no email - or add notes and email - etc..   I built all this out and then concentrated on automation..  We run pretty lean here so anything I can automate is fantastic..  SD was able to accomplish simple tasks for me as long as they were static..

    Event ID 6000 ( Application log full )?  No problem, execute a agent procedure to save and clear the application log.   4199?  IP release and renew..  I was getting somewhere - but what happens once something is not so static - like I don't know - checking a certain windows service status based of a variable in a ticket?

    At this point - I had a few choices - which I tried - read forums - asked support - never really got the answer I wanted or the solution didn't do exactly what I wanted or as fast as I wanted.  SO I had to come up with my own solution..

    *** This is where I warn you - do things at your own risk and always have a backup - crashed server, loss of data, unwanted pregnancy - all not my fault ***..

    Here is how I accomplished it and how we use it:

    I jumped into SQL and created a very simple table in the Kaseya Database Called dbo.xService.  
    This table contains 2 columns - machID and sName.

    Next I created a simple SQL commands for SD
    Write Failed Service Name - This writes to the 2 columns in my table using variables. [$FullMachineName$] and [$ServiceName$] ( ill explain later )


    Created 2 simple SQL commands for Agent Procedures
    Query Failed Service - reads the service name based off of the machine ID
    Delete Service Record - deletes the record after we are done

    Time to jump back into SD and make all of this work!

    I added a bunch of Custom Fields - ServiceName, ServiceState are the 2 I will concentrate on right now..  To populate these 2 custom fields - I suggest you look at Ticket Request Mapping and the [$SourceType$] and [$SourceValue$] variables..  These variables provide a wealth of information about the alarm that was triggered and if your not using them even in your normal SD procedures - your missing out..

    My Request mapping checks the ticket property for the Source Type of "Service".  If it matches it then assigns 
    ServiceName = [$SourceValue5$]
    ServiceState = [$SourceValue3$]

    Now that my custom fields are all filled out, the rest is simple.

    A service fails and a ticket is created.  SD writes the custom fields and passes it through the stages.. My "Analysis" stage detects a service failed, executes the SQL statement to write the Machine Name and Failed Service to a table, SD schedules a agent procedure on that machine id, then deletes the ticket.

    My Agent procedure then Queries the service - checks if its running - then tries to get the service started..  Based on the results, that procedure then emails a ticket into our connectwise board as either Remediated or Failed Remediation..

    This has lowered the amount of tickets overall and *most* of the time if we get a failed remediation - something is seriously wrong.  Hopefully this will help and you could follow..  We know use similar procedures and SQL commands on a ton of different issues from remediation to pop up messages on techs machines when a server goes offline or a end users machine when the C:\ drive is low..   ( couldn't you do that anyway ) - Yes, but our pop ups tell you which server went offline and tells our end users how low the disk is..

    I am hoping that one day this all will be useless and that variables can be shared across all modules - but for now this works and has really helped.

    --sorry for typos and incorrect grammar - typed this up quick as I have been meaning to do forever--

  • Hi Born, I just wanted to say thanks for posting this!  As one of our biggest annoyances with monitoring right now is that Kaseya will always alert whether or not the service restarted successfully.  If this can get rid of all those 'false alarms' it will be a great help.

  • HI Guys

    There's a feature request in the system for this .. so can you add a post to the request to help given a bit more weight





  • PS .. just as an aside .. we do our service remediation the other way round .. i.e. we do the Service Restart and Check in an agent procedure and then only if the service did not restart will we get the agent procedure to create the ticket

  • Born is my other account - you can see more on this on the contest that just ran:  community.kaseya.com/.../93525.aspx

    Paul - thank you for the link and also not a bad way to do it - I just wanted a procedure to try a couple times to restart before the ticket.   You can also build in a complete kill of the process if it is in "starting" or "stopping" for to long and try to get it running again by having the ability to pass the variables..   This concept was built using services as a example, but I use the same concept to do multiple things.   A few so far:

    1. Alert our engineers when a server goes offline.  We get a pop up on the screen with the server name and when it went offline - as well as a annoying beep that's hard to ignore.

    2. Low disk space - alarms, runs some powershell, sends ticket, ticket is analyzed to see if it still below x - then either closes it or continues the process.

    Really - I want this feature more then anything else..  Once Agent Procedures and Service Desk variables can be passed - it will change the way everything is done - true automation based on ticket values..  A ticket that contains every automated step performed, plus results, remediation, etc would really be great.   If, in a single ticket, you could show, X alarmed, Y was done automatically, Z was the result and not 1 person had to touch your system - it makes "managed services" valuable..

    Thanks for check it out and definitely vote that feature up..

    Good luck and thank you!

    **missed a word
    [edited by: Paul Borginis at 5:21 AM (GMT -7) on Aug 25, 2014]