Jump to content

FocalFury

Members
  • Content Count

    18
  • Joined

  • Last visited

Community Reputation

0 Neutral

My Information

  • Agent Count
    3000+

Recent Profile Visitors

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

  1. Hi all, Recently we saw a thread in r/msp https://www.reddit.com/r/msp/comments/ani14t/local_msp_got_hacked_and_all_clients_cryptolocked/ where an MSP had their client's machines all had ransomware installed due to an insecure plugin with Kaseya. This got us thinking about security overall with CWA and what we can do to increase our security posture. What do you do to improve security with regards to CWA. We are reaching out to vendors that we have 3rd Party Plugins, as well as our Account Manager for information. We're also considering blocking MYSQL ports to the DB server over our LAN except for our frontend server (in a dual server split). Is this a good/bad idea? We do have 2FA on all CWA accounts as well. What else should we be considering?
  2. FocalFury

    Internal Monitor RAWSQL Hanging

    Adding to this as I work with David, I'm our LT Admin and we are both logged into the same Remote Desktop server, just on different sessions. When I run the query it works for me, and then switch back over to him and it won't work. Other RAWSQL Build and View Query works for him though.
  3. FocalFury

    Windows 10 Enterprise 1607 fails

    Anyone get any further? I have about 300 machines I'd like to start upgrading to 1607
  4. SHELL with powershell.exe -command worked Thanks for that reminder
  5. Hi all, I'm trying to script within LT the running of a powershell script. I need it to launch as admin otherwise it does not output a result. I've tried running it with SHELL, SHELL as Admin, Execute Script, nothing seems to work. Does anyone have any ideas on this? Let me know if you need extra information.
  6. it was at 8 for the first batch of tests, I set it to 0 and the tests after didn't make much change in numbers. I agree now it should be 0
  7. Thread concurrency is now set to 0 I'm at MYSQL 5.5.31
  8. We set it to 5000 as that is what was recommended and a good starting point. Here is what I have now, and this is while we have 57 scripts actually running. "Variable_name" "Value" "Threads_cached" "37" "Threads_connected" "157" "Threads_created" "5233" "Threads_running" "2" Running my 500 scripts again with the max set to 250 allowed and when we were at the max 250 running: "Variable_name" "Value" "Threads_cached" "27" "Threads_connected" "331" "Threads_created" "5398" "Threads_running" "2"
  9. Couldn't agree more on the need for an expert. When LT made these recommendations I flat out said. "I'm glad you are authorized to give suggestions on this topic, but just so you know everyone is telling me something different with the my.ini. We're at these settings because someone told us to put them there." Thankfully he pulled out the basic recommendations from someone that was an expert and so I was happy to make these changes. They really didn't do much though, but it was worth a try.
  10. I've a few threads recently here regarding abhorrent performance with scripting getting backed up in both 10.5 and 10.5.3 While I understand LT 11 is 'supposed to solve this', to be fair that is what I was told for 10.5 and 10.5.3 with no changes. I decided to do some testing and research as to why everything was getting backed up. First off, noticed the built in out of the box Agent-Maintenance Contract* was taking around 4-5 hours to run on all 4400 agents we support. Seeing as it runs on offline agents as well as online, decided to just change the schedule from 6AM to 6PM and wait for the fix. With our maximum allowed running scripts set to 1000 (LT Recommendation to solve our problems) I ran some tests. I then tested running this script once on a single agent. It took 35 seconds to run. Then ran it on a group of 30 agents. They took between 31 and 41 seconds to complete. Next was 500 and this is where the results started getting UNBELIEVABLE (IMO) The fastest script was 1m9s and the slowest script took **15m48s** That is 30 times longer than the single agent took. Of note is we were still under 600 max running scripts in our entire organization (no other scripts clogging) Changing only the max running scripts allowed and restarting the DB Agent I performed the following tests and got the following results for the slowest script to complete running. (fastest script completion time didn't change too much) 50maxrunning= 53s 100maxrunning= 1m9s 250maxrunning= 7m8s 500maxrunning= 19m30s 1000maxrunning= 15m48s 2000maxrunning= 27m30s Data like this makes it understandable why when running the Agent Maintenance Contract* script on all 4400 agents takes around 4-5 hours to complete them all I think it is crazy that without hitting the script queue limit and depending on how your maxrunningscripts value is set you get varying and lengthening times it takes for scripts to complete. Labtech recommended a few changes to the my.ini file which I adjusted and then re-ran the tests on 1000 max running allowed and 250 max running allowed (twice). There was no major change that would be explained by these settings being changed. The frustrating thing is I was recommended by LT to increase from 500 maxrunningallowed to 1000 maxrunningallowed. I didn't think it would solve the problem but I never thought it would hurt. Granted these tests have other variables that are hard to quantify. I tried my best to note other things like how many other scripts were running at the time of testing. Here is a GoogleDocs spreadsheet if it will help anyone. It is sort of a story meant to be read from left to right in terms of the sheets. https://docs.google.com/spreadsheets/d/16so43k7lK3DSpJd9EIbagG6-Sf9YE_lWeHMLYJXoqoM/edit?usp=sharing We've set our maxrunningscripts allowed to 250 for now until we can get another call scheduled with LT to understand what the next steps are.
  11. FocalFury

    Patching nightmare

    That sounds like a network issue rather than a patching one to me. Maybeeeeee one of your updates was a NIC driver that botched it? Thats the only thing I can think of that might be close to putting it on an update
  12. Wow that is pretty cool! I'm gonna keep this idea in mind. BTW if you are still having the reading from stream errors I created the following Powershell script that you can run that might help you. It is set to run every 15 minutes. This batch runs every 15 minutes from task scheduler on the LT Server @echo off Powershell.exe -executionpolicy remotesigned -File C:\Scripts\LTAScripts-Error-Detection.ps1 This is the powershell it calls ##Created by focalfury $date=(get-date -Format d) -replace("/") $time=(get-date -Format t) -replace(":") $originalfile = "C:\Program Files\LabTech\Logs\LTAScripts.txt" $newfilename = "LTAScripts"+"$date"+"_"+"$time"+".txt.old" ## $PSEmailServer = "your.mail.server" $Log = get-content "C:\Program Files\LabTech\Logs\LTAScripts.txt" if ($Log -like '*stream has failed*') { Send-MailMessage -to "Recipient1 ", "Recipient2 " -cc "Recipient3 " -from "LT Server " -subject "LT Error Detected" -Body "The LTScripts.txt file contains 'Reading from the stream has failed' This script has run 'restart-service LTAgent' in Powershell to try and fix it. Please log in to the LT Server and open SQLYog. Run query SHOW FULL PROCESSLIST. Sort by command so query is at the top, then continuously press the green refresh icon to the middle right. You should see query constantly changing noting that commands are processing. If it is static and non-moving, we should restart the DB agent manually." Rename-Item $originalfile -NewName $newfilename New-Item "C:\Program Files\LabTech\Logs\LTAScripts.txt" -type file restart-service LTAgent } else { Exit } ^^^^Basically looking for 'stream has failed in the log'. If it finds it it appends date/time to the log file, creates a new LTAScripts.txt file so that next time it looks it doesn't find last time's error. It sends an email for visibility the problem happened. It restarts the service. It was a great solution and worked great for us....frustrating to get that E-Mail 5 times a day. Glad to not get those E-Mails anymore.....wish the underlying issue was fixed.
  13. Thanks for the info peterm Good to know I felt right about upping the script count wasn't going to solve the issue. Every morning I get started and we're at around 6600 scripts in the runningscripts SQL table I've moved things around a little bit in terms of the nightly scripts not running too close together, but they weren't too close as it were. The monitor is a great idea I'm going to keep that in mind.
  14. I was going to create a scheduled task as well. However, my experience lately is that the service has trouble stopping and restarting and is requiring manual intervention. How many agents are you/max scripts just for reference?
×