We've had a quite a few issues with updates that report 'Error On Endpoint:Couldn't resolve host name' or 'Error On Endpoint: permission denied' in addition to issues with the monolithic zip file with patch information not downloading.
We escalated a support ticket and they haven't figured out the first two 'transient' issues, but they are aware of the large patch info zip file issue, which is supposed to be fixed in the most recent releases - we haven't moved beyond 184.108.40.206 yet - so hopefully it will get better.
We worked around the zip file issue a bit by changing our scanning days to be Monday and Wednesday and avoiding Tuesday when the file is released.
Yea, SM is crap, just doesn't work consistently and needs a dedicated resource to fix things daily, who has time for that. That said, the latest Kaseya patch brought on the ability to let Kaseya manage the local Windows Update process on the endpoint instead of letting SM do the scan and deployment. I would like to use SM to do just that, allow the local machine to use the default Windows Update, but we simply retain control of the maintenance windows as to when patches get deployed as well as the reboot method. Does anyone know if that is possible? If so, would love to understand how to configure the policy to do so. The new policies for this are extremely long and seemingly complex as they represent a bunch of GPO selections i believe, but i'm thinking that i'm over-complicating it and probably don't have to worry about most settings. Just want to know if anyone's had success here.
Our MSP is working with Kaseya support on this exact problem. It's been ongoing since January 2020—only four months after we 'went live' with Kaseya after purchasing. Things aren't looking good.
As part of the troubleshooting process we tried configuring the 'let Windows handle it on its own' approach, but we decided it wasn't worth it for a couple reasons: First, why wouldn't we just use GPOs to manage that? From the servers themselves? Second, we lose all visibility with this method. We'd have no idea if patching is working or not. Patch reporting is critical if our client asks if patching is working. It's just a messy approach, and doesn't satisfy that 'pillar' of I.T. (patching). Third, that strategy doesn't patch third party apps like Kaseya's SM is advertised to. So even if Windows was managing things on its own, we'd still get tickets for updating Java, Adobe, and all that jazz.
At the end of the day, SM needs to work as advertised. That's it. If it doesn't work (and we WANT IT TO), we'll have to find another solution to replace Kaseya unfortunately. Neither Kaseya OR us wants this, but it is what it is. I wish you and your MSP the best of luck!
Oh it's been going on much longer than that, so welcome aboard. They had a Patch Mgmt module that worked great, then they moved to Software Mgmt and it just doesn't work. Been battling this myself since Q1 2019, and I have direct lines to the folks that are in charge of development. This move very slowly. Anyways....this new feature to use SM to manage the local Windows Updates is just that. I fully expect that visibility is still retained in the SM module, and you can report on it, etc. Otherwise, i would agree with you. Not exactly what i was saying though. I understood that we could use SM sorta like you use WSUS. Still central management, you're just not moving the scan/deploy process from the workstation over to the VSA server(s). The latter is what doesn't work. So i want to push it back to something that does work (aka the local machine), just control the schedule, reboot action, and reporting, of course.
What version of Kaseya are you using hosted SAAS or on-prem server. We are hosted on 220.127.116.11 and I have no issues with SM. The only real issue I have with SM is updating server 2008 R2 fails a few times before it finally takes but we are in the process of upgrading all servers to 2016.
There are a few things I wish they would address
• Patch approval
o I wish we approved patches per patch and not per machine, this way I don’t have to keep approving the same patch
• Install progress
o I wish there was a better progress bar during installation
We began our journey in a hosted environment and had positive results with Software Management. But, we couldn't link our hosted server with BrightGauge—reporting was impossible unless we moved on-prem. So, we moved on-prem. We can report on patching beautifully now. Problem is, patching stopped working once we made the jump to on-prem.
I'm on-premise which is irrelevant, and always stay patched. Server is built and configured via Kaseya standards and approval (confirmed). Been working with them on these issues since Q119, so going on a year and 1/2. So been broken since we signed up, so we're looking for another product.
Here's one problem, and yet another admission below. These are release notes from the latest Patch 29, which was released today. I also got an email this morning from the Support Director that also suggested that there are other "under the hood fixes" for the SM module in Patch 29, so certainly the release notes aren't listing all of the issues that they know exists. This was in response to me complaining yet again. It's just broken, and have zero confidence that it's going to be fixed during our tenure as a Kaseya partner as that will be coming to a close as quickly as we can.
Re: Patch 29
Fixed the issue where Software Management schedules may have been removed as a result of agent update".
I'm sorry to hear you've been experiencing pain similar to mine, but for an entire year longer. That's nuts! Also, I was totally unaware that patch 29 had been released—I'll probably check with our "patching doesn't work" ticket owner before I apply the update, as I don't want to mess up what he's been doing.
As for severing your relationship with Kaseya goes—we aren't there yet, but we will be if we can't patch in the next few months. In an effort to save you time, I can tell you first hand that CW Automate can't patch either (at least, not during April 2019, which is when we dumped them because patching didn't work). I am a [beyond] full time centralized services resource with a vested interest in growing the company, with 11 years of experience, and I can't make it work.
I was talking with my boss today about this, and we agree: It's like the big dirty secret of all MSPs. Patching just doesn't work. If Kaseya and ConnectWise both can't do it, who can? Microsoft, I guess...
Automate is probably the worst of all RMM tools as their monitoring doesn't work either, nor does their version of "live connect". It's extremely slow to get to file transfer, remote command line, etc. And support is the pits. That said, we love ConnectWise Manage, that's our PSA tool and no issues there. We migrated from Automate to Kaseya 1.5 years ago. I think Kaseya is a great product other than patching, and our support experience this time around is way better than it used to be (i used Kaseya 10+ years ago and it was horrible support). If patching worked, we'd be happy as clams. And it used to work via the Patch Management module until MS changed how they do things and Kaseya forced us to use Software Management. It's just obvious that Kaseya doesn't have the development chops or talent just yet to figure out how to make it work, and we're kinda done with waiting. It's no longer a convenience thing or us not being patient, it's putting us and our clients at a security risk, and that's not acceptable in this day and age. Plus, if you're a cyber security company as we are, it's pretty embarrassing that we can't patch our own s*%@ with our own RMM tool. We have to use something else. Not a good look.
We put all of our MSP / IT clients back on Patch Management and use NinitePro or Choco for 3PP. Very reliable, and high compliance rates. Enterprise patching model with 9 standard change windows per month and 9-12 schedules per change window for server patching, managed via an Excel spreadsheet. App-groups are patched & booted in the right sequence within a single change window, and servers can be scheduled for manual patch initiation, auto initiation with manual reboot and more, all through the Excel file.
We had been working with Kaseya engineering on S-M updates and providing feedback, but sadly it seems like its being driven by others than engineering. We get more updates on flashy new features than solving core issues like load, scheduling, and reporting.
Not sure why it's so hard to get reliable patching and feedback. I have a system that I wrote years ago and still use at home that allows me to schedule my servers and even specific workstations to within 1 second of start time and day, control updates, and collect results - all from a single configuration server. Every system in the lab updates each month, on schedule, within its assigned 3-hour change window. Not saying that editing an INI to schedule servers is a production app, but it's worked with either WSUS or Windows Updates for the past 19 years and I can check results of all updates in one place. No - it doesn't apply Windows Upgrades. :)
We use Manage in-house and really like it. We are about to release a fully-integrated VSA ticket processing system for Manage that will update open tickets, create new tickets and assign T/S/I classifications, get ticket numbers for on-call notifications, and page the on-call team for high priority events for select clients within specific operating hours. The intelligence in the workflow engine has close to eliminated unwarranted after-hours calls that wake up the team.
In our upcoming VSA Feature release (Labeled 9.5.1) - will include a multitude of enhancements and fixes to Software Management. One of them being a progress bar for scan/deployment tasks.
As for the framework of approval for Software Management - Machine based versus profile based; I am aware of this workflow which software management was initially built and I am working with our engineering team to assist me in building a method to allow the ability for profile based management.
I've just moved over onto patch 18.104.22.168 and so far, SM is working better than it did previously.
There are still numerous issues (some more of a design issue than software bugs) however it is working well enough now to start to re-test it in a customer environment. Progress is being made. Slowly.