Jump to content

Create Remote Monitors from Scripts

Recommended Posts

I've got a working script to create Remote Monitors, they get input into the `agents` table and show up on the Agent(s) as expected.


The hang up is that they sit in a dormant state until the Daily Maintenance processes get run. I can kick them off manually (Help -> Server Status -> Do Daily Maintenance) after which they begin working as they should.


I worked on this a bit back on 2012.1 and was told by Support that it should be resolved in 2013 - that didn't happen. He did say that he thought it had to do with a particular Stored Procedure that gets kicked off during the maintenance but could not help me further as it was out of scope.


Do any of you have an idea if/which Store Procedure(s) or other background processes are the ones that kick these monitors into action?


The process I'm using to get them into the database is two-step


Set all the variables that would be needed

SQL EXECUTE (INSERT INTO query) the `Agents` table


My INSERT INTO statement is this:


INSERT INTO `agents` (`Name`, `LocID`, `ClientID`, `ComputerID`, `DriveID`, `CheckAction`, `AlertAction`, `AlertMessage`, `ContactID`, `interval`, `Where`, `What`, `DataOut`, `Comparor`, `DataIn`, `LastScan`, `LastFailed`,`FailCount`, `IDField`, `AlertStyle`, `Changed`,  `Last_Date`,`Last_User`, `ReportCategory`, `TicketCategory`, `Flags`) 
VALUES('@name@', '@locid@', '@clientid@', '@computerid@', '@driveid@', '@checkaction@', '@alertaction@', '@alertmessage@', '@contactid@', '@interval@', '@where@', '@what@', '@dataout@', '@comparor@', '', '@lastscan@', '@lastfailed@', '@failcount@',  '', '@alertstyle@', '@changed@', '@lastdate@', '@lastuser@', '@reportcategory@', '@ticketcategory@', '')


All of the variables above are defined at the top of my script so it inputs into the database as expected (attached screenshot from SQL YOG)


Share this post

Link to post
Share on other sites

Everyone seems to be as stumped by this as I am. Support gave me a brief rundown of what the "daily maintenance" process does:


We pause the scripting engine.


Do a daily backup of the database


Restart the scripting engine.


Do the group patching application


Do database maintenance which validates groups and subgroups, make sure the database agent password is set properly, trim all history for orphaned/old records, and move items to their respective history tables, as well as drop the oldest event logs, ensure we have guids set on scripts, extrafields, and mastergroups


Refresh all settings as current from the registry.


On Sunday nights we delete orphaned records that don't match to stuff like computer ids that don't exist.


My assumption is that there is a stored procedure run during the Database portion of the Daily Maintenance, but I haven't had much luck tracking it down yet.

Share this post

Link to post
Share on other sites

Interesting Development.


I found a table called 'h_agents' that contains historical information on remote monitors and thought I'd try inputting information into this table also.


I did a SQL INSERT command with the following:


INSERT INTO `h_agents` (`agentid`, `checks`, `fails`, `failurerate`, `lastfaildate`, `lastfaildata`, `lastsuccessdate`, `lastsuccessdata`, `agentstarted`, `lastcomputerid`)
VALUES ('@agentid@','@checks@','@fails@','@failurerate@','@lastfaildate@','','@lastsuccessdate@','','@agentstarted@','@lastcomputerid@')


The variables translate to (I did a LOG step so I could view this):


 VALUES ('376404','0','0','0','3/24/2014 1:25:23 PM','','3/24/2014 1:25:23 PM','','3/24/2014 1:25:23 PM','1900')


What I got was this:




Went back to SQLYOG and found that despite the date values I entered above, this is what the DB holds:




It appears to be checking for the Event ID (the 'last check time' value is updating itself), but the 'installed on' date is way off. Also, the "counts" field in the screenshot above does not changes, it's still listed as 0 counts, 0 failures.


Any idea where this went wrong? I think I'm getting pretty close.



Share this post

Link to post
Share on other sites

Small Update, I think the issue is with the %when% variable, it adds the AM or PM indicator to the value.


Since it's not stored in the DB with that value appended on tot he end, I'm assuming this is causing the trouble.

Share this post

Link to post
Share on other sites

LT Support pointed me in the right direction. I was way off. :)


The problem is not with the h_agents table at all. It's with the %driveid% value. When I viewed a monitor in the DB, it had a %driveid% value of 1, so I mirrored that in the script. Well, actually, it should have a value of 0. Apparently, part of the Daily Maintenance process goes through these and makes them 0 if they are not already. That is the action bringing these monitors to life.


Edited the script to use a %driveid% value of 0 and confirmed it working. Also removed the steps I had put in for the h_agents table.


Here's the updated Script.





The script uses a parameter passed at the time of scheduling called @TechContact@.


This value should be the email address you would like notified when XYZ Event ID occurs.


Create a contact called "EventLog Finder", firstname "EventLog"


Create an Alert Template (and make sure the script has this alert template ID, the @alertaction@ variable) using the "EventLog" contact, set the "Action" of the alert template to be set to EMAIL.


Now, when you run the script, enter in the email address to receive the notification into the @TechContact@ value. The script will then update the 'EventLog Finder' contact with this email address. Now, when the Event ID is detected, that email address will receive a notification stating as such.


My next addition will be a process that removes the monitor after it alerts. As of now, it has to be manually removed when desired.


Feel free to ask questions or take the script into a new direction if you'd like.

Finder - EV Search and Alert.zip

Share this post

Link to post
Share on other sites

Created an Automated Removal process. My goal was to have the monitor created, send a notification, and then be promptly removed as it had served it's purpose.






The Alert Template needs to have a secondary alert action added which will run the Removal Script.




In my tests, I get the email notification and within 20 seconds, the Remote Monitor has been removed.

Finder - EV Search and Alert (Remove Monitor).zip


Share this post

Link to post
Share on other sites

I had a problem getting my monitors to install until I added an Install Monitor script step.

It's LabTech Command 84 and I add the following line in the parameters (this is for a ping monitor):

@newAgentID@|@ispAddress@|0|1|30|ex %00||4|False|0


@newAgentID@ is the ID of the monitor in the agents table

@ispAddress@ is the ip address that it's pinging

The 30 is the interval, 4 is because I'm alerting after 4 missed pings


I'm not sure what the rest is. You can get the parameter string for the monitor you're trying to create by creating a monitor in the wizard and finding the command in the commands tab. It should list the string there, or you can right click on the command and create a script from it.



Share this post

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...