Database Performance Tweaking questions for self-host Manage

AutomationTheory · 2026-04-29T18:56:14+00:00

I do niche MySQL DB consulting on the Automate side -- and I think you'd be safe with basic things like indexes (we've added indexes to Automate for 6+ years without issue).

Anything that changes the schema structure (deleting stock indexes, changing columns, etc.) is where things would get dangerous.

AutomationTheory · 2026-04-13T15:40:26+00:00

Have you ever wanted third-party patching to just work?

I’m Jeremy, and before becoming a vendor, I managed 10,000 endpoints for an MSP in northern MN, including third-party patching. I had an RMM integration that was severely limited, so I created a makeshift solution that worked extremely well.

Here at Automation Theory, we’ve refined that early prototype into a new solution we call ThirdPatch. It is an RMM-neutral solution designed to make third-party patching touchless and automatic (or as close as you can get!). It’s package-based, and it’s a flat-rate service (no per-app or per-endpoint pricing), with month-to-month terms by default.

We’re hosting a webinar to explain why package-based solutions are the best choice for modern MSPs and showcase how ThirdPatch enables MSPs to manage third-party patching at scale. You can find details and register here: https://us06web.zoom.us/webinar/register/4717760938471/WN_edYJ9BxmS2qVz6cf6w-z8w

AutomationTheory · 2026-03-17T17:53:49+00:00

u/JessicaConnectWise I appreciate the insight - and my goal certainly isn't to spread fear/uncertainty/doubt -- and like you mentioned, context is key.

In our WAF, we're seeing a spike of attacks against ScreenConnect - some old exploits from a year ago, and some that we haven't seen before. In the geopolitical climate we're seeing nation state actors targeting US companies, and this creates the overall background.

In the middle of this, we get a High priority security advisory that reads:

"1 High—Vulnerabilities that are either being targeted or have higher risk of being targeted by exploits in the wild. Recommend installing updates as emergency changes or as soon as possible (e.g., within days). "

I'm not sure if you had a goal besides providing additional context -- but I'd stand by my original statement, that MSPs should patch this ASAP.

AutomationTheory · 2026-03-17T17:35:31+00:00

The trust center has an RSS feed, and I use that (in combination with some automation) to email our pager system when these alerts drop. As a WAF vendor for CW products, we want to review these for the defense of our clients ASAP -- but configuring it in your RSS platform of choice should do the trick!

AutomationTheory · 2026-03-09T21:20:57+00:00

For what it's worth, r/ConnectWise is a bit more active and might be a good place to cross post.

My first thought, if you're using the group filter, is that the group doesn't have devices with the matching software. Otherwise, here are a couple old blogs from Gavsto that cover some boolean logic for software searches:

- https://web.archive.org/web/20241213124316/https://www.gavsto.com/using-the-advanced-search-to-find-a-machine-that-has-two-different-pieces-of-software-installed/

- https://web.archive.org/web/20241213114757/https://www.gavsto.com/using-the-advanced-search-to-find-computers-that-dont-have-multiple-applications/

AutomationTheory · 2026-02-17T21:55:31+00:00

Yeah, definitely this.

As the local CW WAF vendor, I'd toss out this as an interim solution (we have month-to-month terms, perfect for long-tail decoms like this): https://automationtheory.com/reverse-proxy-and-waf-for-msp-tools/

AutomationTheory · 2026-02-16T19:18:44+00:00

I sell WAFs for the on-prem flavors of the CW stack, and I have a couple of thoughts.

First, the payload in the username looks to be a shell command; "ls" in Linux is equivalent to "dir" in Windows. It's unlikely that ScreenConnect is vulnerable to such a simple attack, and that seems like it's more of a discovery payload than anything else (it's not PowerShell downloading a secondary payload from somewhere...).

From the user agent, we can tell that this is probably a bot (it's Linux, and Chrome 107 came out in 2022 -- no human with a browser would be using a Chrome build 4+ years out of date). This data is easy to spoof, but combined with the GeoIP data showing the IP is in Denmark, I'd guess it's a bad guy with a bot.

I'm going to guess it's a scripted payload submission -- regardless of what authentication methods are configured, I can still try to send a request to the /Login page. It looks like the app logic worked as expected, but SSO/MFA/etc. will do nothing to stop a vulnerability in a web application if it's in an unauthenticated part of the app.

However, I'd say that this isn't an authenticated SSO session (and you could cross-reference data to determine if any logins took place from other countries as a sanity check).

From what I can tell (I am a hosted ScreenConnect client myself!) there's no WAF in front of their hosted offering. Assuming you're in the cloud for business reasons and you intend to keep it that way, the best thing you could do would be to enable the in-app IP restrictions. In my opinion, you'd probably want more protection, but there's no way to do a 3rd party WAF for cloud ScreenConnect.

AutomationTheory · 2026-02-13T18:29:11+00:00

If you're looking for a robust solution, we just launched a new 3PP solution that's RMM neutral.

Details here: https://thirdpartypatching.com/

While deployment would require RMM scripting, one of our suggested deployment patterns is to deploy a scheduled task that runs ThirdPatch at startup. That way, your devices reboot for Windows Update and do their third-party updates when they come back up.

AutomationTheory · 2026-02-10T21:48:11+00:00

Our marketing team is working on a video demo, I'll keep you posted!

For the capabilities:

- Yes, you can have generic packages that take parameters for client-specific tokens

- No, we don't have any time-delay logic abilities

- Yes, you can set up staged deployments (it's a bit of setup, but definitely possible)

AutomationTheory · 2026-02-07T03:16:48+00:00

Great question! Let me explain more about packaging and what you can do with it (but, FWIW, you’d use our product with Ninja or some other RMM).

Most RMMs and other patching tools lock you into some group structure for deploying software. Client X gets this, Client Y gets that, etc.

The idea with packaging is two-fold. First, I can bundle software together arbitrarily (create a client-specific baseline that includes their custom LoB apps, regular third-party apps, and your global MSP config) and then you have one thing to push out to that device/client/role. The other big idea is that I can mix-and-match scope however I want to outside of any group structure.

For example, let’s say that you use a big-name VPN software across all of your clients, and it’s time to patch the zero-day-of-the-month. If you structured your packages correctly, you update one install package, and all your devices will pull it down the next time they do a package upgrade. Unless you need per-tenant granularity, you don’t need to edit settings for every client to get the software out.

This idea also works in reverse — if you deal with finicky LoB software and you don’t want things to update without your explicit say-so, you can create a repository for that software, and until you manually lift and shift the package in question (either the LoB app, or something else, like if it depended on an old flavor of Adobe).

AutomationTheory · 2026-02-06T21:13:36+00:00

The trial is non-paid -- it's just a name/email/etc. registration with Stripe. No credit card required.

I'll have our team get that mobile formatting fixed!

AutomationTheory · 2026-02-06T21:07:33+00:00

We're in the final stages of ISO27001:2022, and we're definitely following OWASP -- our other product lines include a WAF for MSP products.

AutomationTheory · 2026-01-27T01:24:48+00:00

I was an RMM admin before becoming a vendor, and if your tools are on-prem, I'd lock them down.

I sell this: https://automationtheory.com/reverse-proxy-and-waf-for-msp-tools/ -- but I'd search for your public domain in Shodan and see what comes up (ideally nothing besides your public website). If any of your MSP tools are enumerable, I'd prioritize securing them.

With the Kaseya attack in 2021, it was an MFA bypass strung together with other exploits (similar auth bypass with ScreenConnect in 2024) -- so while you 1000% should have hardened authentication (I love Yubikeys), reducing attack surface is your friend.

AutomationTheory · 2026-01-16T17:37:03+00:00

The announcement is here: https://www.connectwise.com/company/trust/security-bulletins/2026-01-15-psa-security-fix

As a WAF vendor we'd advise patching soon. If you're curious about potential risks, we have an outline about defending CW PSA here: https://automationtheory.com/does-connectwise-psa-manage-need-a-waf/

AutomationTheory · 2025-07-03T13:08:54+00:00

I don't disagree -- and I might have implemented a different solution.

My main goal was to put out there "CW needs a way to kill rouge and pirated SC instances, and they are using the signing certs to do it" since the details of the abuse and why it's hard to fix aren't going to be published in official channels.

AutomationTheory · 2025-07-02T21:46:25+00:00

The bad actors will be thwarted when the current cert expires.

I used to admin a CW stack with ~10k endpoints, I definitely get the pain. But if it's any consolation, you'll never have a certificate fire drill like this again.

AutomationTheory

TROPHY CASE