It seems i'm not alone when it comes to agents failing. There are a few kludges i am thinking of. Have a watchdog script on the client computer to restart the agent, or running an agent script on another computer do do the resurrecting.
Problem with solution number one is that i don't really know how to detect when the agent goes zombie. From the agent's standpoint, it never goes down.
The second solution would be through Agent Monitoring -> Alerts -> [Select function] Agent Status -> Agent hasn't checked in for [X] minutes -> Run _this_ script on _that_ machine. For this, i would use sc to stop and start the zombie agent using _that_ machine as a proxy.
My question is, is there an argument passed to _this_ script so that _that_ machine knows which agent to resurrect?
#id# = machine id
#gr# = machine group
Of course, that would require that your machine id = your computer name so that you can exec sc correctly.
*maybe* #db-vMachine.ComputerName# will work, but it says that is only available as an email variable, not a procedure variable.
With a bit of modification (remove the prompt variables and specify them) you can hook the following procedure into the agent status monitoring and run it from another computer in the same network; community.kaseya.com/.../1033.aspx
The downside is you will need to make a unique procedure for each agent you want to restart :(
Excellent, sirs. I shall try this at once.
Kudos to @Dan for pointing out the variable names. And @HardKnoX, i believe my initial idea was based on your efforts. I decided though that fishing the KaseyaID from the registry would be too much of an effort. Rather, i'd check it from a live session by querying sc and then storing the ID string into a global variable. Don't know if that's bad for security...
OK. Code installed. Now i'll just have to wait for an agent crash :)
The script already locates the KaseyaID for you its the same as your Kaseya customer ID all you needed to do is duplicate the script for each machine you want to revive and change the prompt variable field with constant giving it the computer name or IP address.
I have attached my one that I have developed for automated service restart from another computer in the same network (works best in domain environment) all you have to do is update the top 3 fields.
Also if you want to test it just stop the agent service that you are monitoring...
@HardKnoX -- All my machines have the same name in Kaseya as they do in the field (by policy). If i changed the MachineID and IPaddress to #id# as Dan suggests above, do you mean that It Just Works? Yeah, and the email address; don't want to bother Bob the Builder with my restart mails :)
I wrote a one-liner procedure which dumps out #id# to the file c:\temp\kworking\eyedee.txt. The #id# variable turned out to contain the machine's kaseya "machine.group" name and i can't use that for sc.
Is there a kaseya-side way to get only the machine name or will i need to use some client-side magic to parse the machine name out of that?
That's what I already said in my post, heh.
You could statically "map" machine group to computer name in your procedure if you really wanted to.
Create an if statement to check the #id# and if it's "foo" then run sc on computer "blah". Then create another if statement for the next computer, and so on ad nauseam.
As far as I know, the alerts do not provide a way to get the name of the computer in a procedure.
Use the IP address instead then, not sure how you managed to give all your machines the same name or why you would want to but that's not my problem :). Just to recap on what the procedure does. Agent goes offline which triggers the procedure on another computer in the same network that uses the remote SC command with the provided machine name or IP address (by the script) to stop start the agent service.
A chain of if-statements isn't really what i call elegant programming :)
what am i supposed to do with this xml?i know nothing about xml´s so i downloaded it, but what now?