Jump to content
[[Template core/front/profile/profileHeader is throwing an error. This theme may be out of date. Run the support tool in the AdminCP to restore the default theme.]]

Community Reputation

0 Neutral

My Information

  • Location
    Seattle, WA
  • Agent Count
    500+

Converted

  • INTERESTS
    Coffee Roasting, Taking Hindi Lessons, LabTech (of course).
  1. I found the scripts on another forum posting and imported them to my system. I had the same problem that is mentioned by ErikNSC above (regarding the drives not being identified). I ran the command "ctrl slot=0 physicaldrive all show status" (for both controllers, 0 and 1) and found that the drives are listed as: -physicaldrive 1I:1:1 (port 1I:box 1:bay 1, 300 GB): OK -physicaldrive 1I:1:2 (port 1I:box 1:bay 2, 300 GB): OK -physicaldrive 1I:1:3 (port 1I:box 1:bay 3, 300 GB): OK -physicaldrive 2I:1:7 (port 2I:box 1:bay 7, 300 GB, spare): OK -physicaldrive 1I:1:4 (port 1I:box 1:bay 4, 300 GB): OK -physicaldrive 2I:1:5 (port 2I:box 1:bay 5, 300 GB): OK -physicaldrive 2I:1:6 (port 2I:box 1:bay 6, 300 GB): OK So I edited the monitor from : "ctrl slot=0 physicaldrive 1:1 show detail" to be "ctrl slot=0 physicaldrive 1I:1:1 show detail" instead and it started working. I guess the drives identify using the full on "1I:1:1" instead of just "1:1" that the monitor was built to use. *Note, the controller 0 uses the 1I: format but controller 1 (at least for me) used the 1E: preface. If anyone has a notion of how to edit the scripts to reflect this though, that would be awesome! As of now, if the monitors are rebuilt, I'll need to edit them again. Marc
  2. 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. Pre-requisites 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
  3. 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. Pre-requisites: 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
  4. Hey Jeff, The reasoning behind the "Server Firewalls" EDF was that one of our clients has a server that they are using purely as a software firewall between two LAN's. Since it's only purpose is to act as a firewall, we bill them less for it than we would a managed server so I needed a way to notate that in the Asset Info. I explicitly set the value, only for that client, in the gather update scripts. (it's looking for that "server firewall" by name). It's probably best to ignore that EDF and its corresponding steps in the scripts. I left it in there thinking that there might be a need for someone else to explicitly define a value for one of their clients. I'm excited to hear how your development's coming along! Marc
  5. 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.
  6. 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.
  7. Everyone seems to be as stumped by this as I am. Support gave me a brief rundown of what the "daily maintenance" process does: 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.
  8. That's awesome, Jeff! Let me know if I can help with anything. Looking forward to your results.
  9. Jeff, Now that's a really cool direction to take it! Have you run the "Gather Asset Information" script? It executes the FOR EACH SQL query that runs the "Gather Asset Information - Update EDF's" script against the results. This is is the one that actually does most of the work and puts Asset Info into the EDF's. The "Gather Asset Information - Create Ticket" script just grabs that info out of the EDF's, formats them, then puts them into a ticket. Here's a screenshot of how I have things scheduled out on my system:
  10. Jeff, Thanks for checking these out! I have a group set aside for my LT server and schedule several scripts against it to automate and monitor a few things (LT database size, broken internal monitors, unsynced tickets, etc). I just added these to run against that group so they are running against the LT server directly. Expanding the idea? I'm intrigued! What do you have in mind? Marc
  11. This requires you to setup EDF's like the ones I have here. Of course, you modify the scripts to suit your needs though.
  12. The ticketing scripts. Gather Asset Information - Update Ticket.zip Gather Asset Information - Create Ticket.zip
  13. Script "Gather Asset Information" is the one I schedule, it will call the secondary script "Gather Asset information - Update EDF's" This is done so that the values can be set from a FOR EACH SQL command which passes the secondary script to each result. Script "Gather Asset Information - Create Ticket" is the one I schedule, it calls secondary script "Gather Asset Information - Update Ticket" Again, this is done so that the secondary script can be run against the results of the first's SQL query. It appends it's findings into one ticket. The end result is I have EDF's that have up-to-date Asset Information as well as monthly tickets which report particular clients Asset Information. For privacy reasons, I have removed client names from portions of the scripts. If you have any questions about how to get this going, or recommendations, post them here. I'd be glad to hear from you. Gather Asset Information.zip Copy of Gather Asset Information - Update EDFs.zip
  14. Screenshot of what the "dormant" Remote Monitor looks like. After the Daily Maintenance is ran, this will show up all green and good-to-go.
  15. 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)
×
×
  • Create New...