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.]]

kgrube last won the day on June 20 2019

kgrube had the most liked content!

Community Reputation

2 Neutral

My Information

  • Agent Count
    4000 - 6000 Agents


Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I'm working on something that does this. Working on automatically pushing changes to a private repo through cmd line using deploy keys at the moment. I'll post an update when I have something for you to test.
  2. I should also note, an example project using that decode library is available here: https://k-grube.github.io/labtech-script-explorer/ You can paste in a script XML and it'll decode the steps and display what the script looks like in plain text.
  3. @DarrenWhite99 and I were poking around in the exported script XMLs and I ended up making this library to handle decoding the XML. That library will turn an xml into json and back. It will also add each step's function definition and function text output, e.g. function 1, param1=1 turns into LTCommand: Update Agent. As part of this process, Darren suggested making a function document that contains every script function, it's parameters and associated function text. The live version of this reference document is available here: https://github.com/mspgeek/labtech-script-decode/blob/master/DOC.md This repository will be updated as needed as changes are made to the live version of Automate.
  4. You should read the Github page, it defines what each of those fields mean. I was referring to the AV qualityCompat key, and the server mitigation registry keys.
  5. I played around with this a bit and Windows Update won't report to LabTech that the January patch is available until the registry key is set and the machine has rebooted.
  6. Thanks datacomm, this is sweet. Much higher reliability than psexec alone.
  7. We have a similar number of agents and are seeing around 500 after a day or two or doing nothing, that's why I wrote this script. This script has a pretty decent success rate but anything that blocks PSExec will cause it to fail.
  8. There's a current known issue where agents will continue to check in if they are online, but never execute any commands. This can cause the script queue to quickly fill up because the script engine will never clear out the scripts on these machines. Left long enough, no scripts will be able to run until the script queue is cleared out. Machines exhibiting this behavior can be identified because all commands on the Commands tab will be listed as executing. Firstly, clear the script queue to allow new scripts to run. Either restart the database agent to clear all scripts, or delete from runningscripts manually. There's two routes to go down now: Do a one-off fix through ScreenConnect Create autofixes One-off through screenconnect: (Optional) Delete from pendingcommands to clear queued commands. Either run this on all your machines (restarting every agent) or create a new session group limiting to machines identified as 'stuck' Log into ScreenConnect web interface Select machines Right click -> Run command Paste in this one liner: net stop ltsvcmon & taskkill /im ltsvcmon.exe /f & taskkill /im ltsvc.exe /f & taskkill /im lttray.exe /f & net start ltsvcmon & net start ltservice This will stop the service monitor, kill off LTSvcMon.exe, LTSvc.exe, LTTray.exe, then try to restart everything. Internal monitor/autofix overview: Create internal monitor Create Autofix, call from internal monitor Create an internal RAWSQL monitor. Note: change the limit on the last line to whatever allows this query to run on your system. SELECT DISTINCT computers.computerid AS `TestValue` , computers.ComputerID AS `IdentityField` , computers.computerid AS `ComputerID` , acd.NoAlerts , computers.domain , acd.UpTimeStart , acd.UpTimeEnd FROM commands JOIN computers ON computers.ComputerID = commands.ComputerID LEFT JOIN AgentComputerData acd ON computers.computerid = acd.computerid WHERE commands.Status = 2 AND commands.DateUpdated < DATE_ADD(NOW(), INTERVAL -15 MINUTE) AND commands.DateUpdated > DATE_ADD(NOW(), INTERVAL -60 MINUTE) AND Computers.ComputerID IN ( SELECT ComputerID FROM commands WHERE status = 2 GROUP BY commands.ComputerID HAVING Count(*) > 2) AND Computers.LastContact > DATE_ADD(NOW(), INTERVAL -15 MINUTE) AND computers.os NOT IN ('Darwin', 'Linux') limit 0, 50 Set Table to Check and Field to Check to `RAWSQL`. Set Check Condition to GreaterThan Set Result to 0 Set Identity Field to `computers.computerid` Paste the code block above into Additional Condition Create an autofix script Import the attached script files Put psexec.exe in L:\Transfer\Apps\toolkit (Or edit the script to where it exists on your L: drive already) Edit lines 5/6 for your info categories for the types of tickets this will make Edit line 22 with the script id of this script in your system. Make sure the last line in the script points to the CTS-Autoclose-Update-Generic function script (I don't know how these script exports work) Add the script to the internal monitor Overview of how the autofix works: Check that the machine is checking in See if the machine's already been fixed by injecting a FasTalk command into `commands` table (Script execution will pause if you try to run an actual command and the script will never complete) Delete all non-complete commands for this machine from `commands` Delete all running scripts (except this one) for this machine from `runningscripts` Delete all pending scripts for this machine from `pendingscripts` Delete all remote monitors for this machine from `agents` Find another machine at this machine's location that is not having the problem Run PSExec commands from this other machine to restart the agent on the original machine Inject another FasTalk command into `commands` table Create/update/close ticket based on value of @status@ variable. As always, use this at your own risk. If you have any feed back for me, please let me know. I'm new at this 'exporting scripts' thing, so it's probably borked. Script contents: lts.zip
  9. I had a problem with the monitor provided where the JOIN onto computers causes drive attributes to be mixed up causing the monitor to alert for the wrong drive in multi-drive workstations. Updated monitor below: SELECT CONCAT(drives.Letter, ': ', LEFT(vs2.RawValue / 17520, 5)) AS TestValue , computers.Name AS IdentityField , vs.computerID AS ComputerID , vs.DriveID , LEFT(vs2.RawValue / 17520, 5) AS 'Fail Chance' , drives.Letter AS 'Drive Letter' , drives.VolumeName , acd.NoAlerts , acd.UpTimeStart , acd.UpTimeEnd FROM v_smartattributes vs JOIN v_smartattributes vs2 ON vs.DriveID = vs2.DriveID JOIN computers ON vs.ComputerID = computers.ComputerID JOIN drives ON vs.DriveID = drives.DriveID JOIN clients ON clients.ClientID = computers.ClientID JOIN agentcomputerdata acd ON acd.ComputerID = computers.ComputerID WHERE vs.AttributeID = 187 AND vs.RawValue >= 1 AND vs2.AttributeID = 9 AND drives.SSD = 0 AND drives.INTERNAL = 1 AND drives.VolumeName NOT LIKE '%recovery%' AND drives.Size > 20000 AND Computers.LastContact > DATE_ADD(now(), INTERVAL -5 DAY) GROUP BY drives.DriveID ORDER BY computers.Name
  10. I wrapped the script in a threshold/retry function, so it'll retry 3 times then create a ticket, then auto-close the ticket if it's successful after that. Seems to just fail for random reasons all the time.
  • Create New...