I have been using Kaseya for over six months now, and even after the recent update to version 5.0, the network monitoring functionality remains pretty much a joke. I don’t understand how this app became so popular in the MSP world. Here’s a list of reasons why:
- No concept of “state” for services – Kaseya keeps track of host state (ie: online/offline) with a nice little icon, but it does not do anything similar for services. Therefore, there is no way to get a complete picture of a network’s current state “at a glance.” Services should not be treated like 2nd class citizens this way, because plenty of services are just as critical as (if not more than) the actual hosts they are running on.
- No alerts when a service returns to an “OK” state – It’s not enough to receive an alert just when a host/service check fails. You need a corresponding alert when it starts succeeding again too, and here’s why: False alarms are pretty much a fact of life with all monitoring applications. There are lots of reasons why a check might fail every now and then (network congestion, etc.). Therefore, I don’t want to have to scramble every time I see an alert just to find out that the service is already back up again. I want the monitoring application to tell me when it’s back up. This is especially important when I don’t have immediate access to a computer (e.g. if I’m on the road and I have alerts going to my phone).
- Graphs are limited to ~2000 data points – This is the problem with storing raw performance data in a SQL database (I admit that I am simply assuming that’s what they have done here). More data makes a slower database, so it makes sense that they would hard-code a limit on the amount of data that can be stored. But how in the hell do they expect their customers to do trend analysis with only ~2000 data points? Assuming a service check every 10 minutes: 60 minutes * 24 hours / 10 = 144 data points per day. ~2000 data points total / 144 per day = a history of ~14 days. Compare this to something like Cacti which can easily handle years worth of performance data using RRDtool.
- SNMP monitoring will bring your network to its knees – Amazingly, there is no way to modify the polling interval for SNMP queries. It appears that the Kaseya agent will simply execute snmpget in rapid succession until you notice that your server’s CPU is pinned to 100% and you are forced to disable SNMP monitoring altogether. Even if they increased the hard-coded polling interval, you still have no control over the size of your graphs due to the data point limit listed above (in my experience, you might get 1-2 days if you’re lucky). What baffles me the most is that you can set the polling interval for WMI monitoring. So why would they not implement this for SNMP too? I don’t get it.
To be fair, Kaseya seems to be paying a lot of attention the user complaints on their forums lately, and they’ve already started to address some of these problems. Hopefully I’ll have less to complain about in the coming weeks.
Update: Due to all the Kaseya bashing going on in the comments, I just want to make it clear that I like Kaseya as a Windows desktop and server management tool. My only major complaints are with the way it does monitoring (hence, the title of this post).
Their remote assistance is a joke too. It works fine if you’re trying to remote to a machine that has the agent already installed, but if it doesn’t you will be explaining to the user how to install an ActiveX control. Good luck with that. Also installing the activeX control will not work unless the user is a local administrator… I ran into someone who wasn’t and they needed my help. I wasn’t able to help them thanks to Kaysea.
Why not just do what everyone else does and have the user download an executable? Because the programmers are half-wits who have never tried to remotely assist a user using their own code. Who the hell uses activeX anymore? Use GoToAssist or PCHelpware instead, they know what they’re doing when it comes to remote assistance. If you’re going to implement a feature in your product do it right or don’t do it at all.
Shows that there are myths. Remote Control utilizes 5 different methods and activex is not necessary. A url link can be clicked to direct download a dll that initiates the connection.
On monitoring, they are great. They listen and have opened up monitoring to unlimited events and alarms. If you are a shoddy msp you will flood the system with millions of events in minutes but as I understand it they are going to add some protections for those situations. They do listen.
anon: dont tell me “they are great” on monitoring until you address at least one of the issues i’ve listed above. otherwise, you make yourself sound like a very uninformed person (which i am assuming is why you posted anonymously in the first place).
if anyone has actual solutions for me, i’m all ears. im not here to bash kaseya for the hell of it. i have work to do, and i would honestly love to know how other msps have been dealing with these issues.
You are right that in the latest version of Kaseya ActiveX is not required anymore and the user can download and run an executable. My mistake. However remote assistance is still garbage because the remote user needs local administrator rights to run. Instead of fixing this, the Kaseya programmers put this in the web interface:
“Attention standard users! Administrator privileges are required to request remote assistance.
On Vista, right mouse click on Internet Explorer and start it by choosing the menu selection Run As Administrator.
On all other systems, be sure you are logged in as a user with administrator privileges.”
I read this as “We are too lazy to fix our broken code. Kaseya remote assistance will not work in all cases, so keep your fingers crossed.” How hard is it to fix this? Not very:
The RealVNC server program (winvnc4.exe) that is included in the Kaseya remote assistance agent listens on port 5900. This can run as a limited user. RealVNC picks up its settings from HKEY_LOCAL_MACHINE/SOFTWARE/RealVNC/WinVNC4, but it also accepts a wealth of command-line options (try winvnc4.exe -h). So it is as simple as changing your script/code that starts winvnc.exe, but it is easier to write a warning that says “administrator privileges are required”.
Hi Guys,
I’m trying the Kaseya Product at the moment, we are a solution provider to small companies and I’m looking for a product to meet their needs. I have looked at other products such as level platforms, heroix etc. From a budgetary and business models the kaseya appears to resemble closet what Im looking for.
Technically though I have to ensure it will do what it’s supposed to. I dont want my techs flooded with useless information which eventually they will ignore .. and then miss something crucial.
I do agree with SNMP being issues and also the Remote control is pretty poor.. it’s much too slow. But to be fair most of these products don’t seem to be built for MSP’s.. to date kaseya seems the closest I’ve found.
As i’m just demoing the product at the moment I’m trying to get some overall research to see how others find it in production but I’m having some difficulty getting info.
Any pointers/comments would be great.
Not to add to the Kaseya bash fest, but be careful. their support is the worst of any of the companies we deal with including HP which is really saying something. Weeks can go by before a ticket is responded to, you can sit on hold for support for several hours with no status updates or anything. When they do respond to online support they provide a terse answer that does not address the problem and then close the ticket. The only way we get any sort of response is to raise our support request through our sales person who sends it to the director. As an MSP if we treated our customers that way we would no longer be in business. Until they fix their support I would not recommend purchasing their product.
We have been using Kaseya for a year and it’s been a long road with a large investment of our time to configure it right. However, in the end it has been worth it. We like the ability to tweak Kaseya as we see fit. Also you can mointor services and then even do self healing scripts which are triggered by stopped services. My final comment would be you get out what you put into it.
I have been using K for about a year and while robust – I’m tired of it. The idea that sold us on Kaseya was that it would allow us to spend less time supporting our clients. Isn’t that what it’s all about? So yes while you may spend less time at running your business and supporting your clients it’s only because you have to spend so much time supporting the new gorilla you just installed at your office. His name is Kaseya!!!
Prepare to either hire a new person just to administer Kaseya or look for another solution.
I finally came to the realization that if I was going to spend so much time dorking around with kaseya I might was well spend that same amount of time on an open source product like nagios or zabbix – why spend the money on kaseya?
Also beware of the sales process — they will sell you a product that cost more that most luxury cars and then if you want training — pay for it — you want to monitor antivirus — to bad if you don’t buy into kaseyas rebranded AVG crap —- you want an easy way to monitor backups —- buy into kaseya backup — user state management — the list keeps getting longer and longer — Look for something else folks Kaseya’s not worth the trouble!
Lance is right… you get out of it what you put in to it. I’ve been using Kaseya for almost a year now and the things you say you can’t do, you can… I can monitor Trend and Symantec (in fact I can use Kaseya to deploy it too), I can monitor BackupExec using Kaseya. I was sold heavily by N-Able that Kaseya couldn’t do these things and when I saw that Kaseya could I knew N-able didn’t know what they were talking about (or they were lying). Either way, I lost trust in my N-able Rep after that, so I suggest you verify anything before you just take their word for it.
And why wouldn’t you deploy agents to every customer you can? I have them deployed to my non-managed/break-fix customers as well so they can log tickets, so I can remote control them… I don’t save money by not deploying agents, but I save plenty of time when they log tickets and when I can remote in to their machines instead of them having to call me to get support. I don’t deal with the ActiveX thing because I’ve got agents on every machine.
Support has been frustrating lately, but I don’t think they’re stupid… They know that bad support will start to lose them customers and my Rep says they are actively working on this.
The monitoring could be better by my Rep says they are actively developing the next generation of Monitoring. I get the alerts I care about, so it is sufficient for me for now… I didn’t buy Kaseya for monitoring, I bought it for remote access and scripting. The scripting in Kaseya was soo much simpler than LPI or N-Able. I can run tasks, deploy applications and updates, etc so much faster and easier than the way N-able or LPI does, even to non-managed customers that I’ll bill a project for, but I do them at the same time as my managed customers and don’t spend extra time but I bill more revenue for it.
C, whether Kaseya is worth the trouble depends on what you want to do, and the stuff you say it can’t do, it does.
I’ve been using Kaseya for almost two years. You get out what you put into it. Remote support is fine, VNC by itself is slow, RDP faster, RAdmin faster, etc. You can use whatever your comfy with.
Kaseya is not the tool to try and hack your way into a new customers machine – which is probably screwed up already. MSPs already have the agents installed, because the MSP should be the admin.
Kaseya is a great tool to manage your clients – it will make you money if you know what you’re doing. I hopped right in without “learning” Kaseya – the tools Kaseya uses should already be known to the MSP. Those tools are nicely wrapped up and easy – read quick – to use. Quick means you can handle more tasks at once – then you turn what you just did into a script. *nix guys like this.
I am not using BUDR (there is a flaw in Acronis that killed a critical exchange server when doing a full disk image). I will be using what the client has (usually BEX) or roll my own with existing tools.
I might consider KUSM because of the ability to bounce back a user or transfer users – in a Windows environ.
Having an OS X client is nice – Linux and PDAs are coming.
I won’t be using KES because I dont like the pricing, and I’m moving back to open source perimeter scanning because the commercial AV software is so intrusive, and it’s targeted by malware, so it doesn’t work anyway – not all clients have wizzy Core 2s or Xeons, or whatever or gigs of memory. Some business don’t like to change much if it works.
It sounds like the top comments are trying to use the wrong tool for the job.
Merlin, you’re dead-on. I’m not using BUDR for the same reason. We were on version 1 when it happened and unfortunately my staff has a long memory when it comes to stuff like that. Even though the problems were sorted out, that initial incident killed it for me.
Andrew, Kaseya was not originally designed as a monitoring tool. It is a network management tool that they added monitoring to. If you bought it for the monitoring, I can see why you’d be upset. There are many, better monitoring tools out there. Things are changing though. They’ll get it right in the next version or two.
However, for network management purposes, nothing compares to Kaseya in my book. You couldn’t pry my staff’s cold dead fingers off of it. We manage over 3000 desktops and servers with it, and it flat rocks.
Hello, this is Corey from the Kaseya Engineering team. I hope it is OK for me to add my two cents as well as get advice from you guys on the short term and long term changes we can make to the Monitoring Modules. I do not own any of the work on Remote Control but I can have another Engineer respond to that (I do know they are in the midst of some significant changes).
I am actively involved with short term changes to make the Monitoring Module better from input from groups like this. The longer term monitoring changes will be part of a program called Advanced Monitoring that is a huge leap forward in functionality, data storage, Network Securityand user interface metaphors that the focus groups are excited about; as well the integration to the most popular open source monitoring and network security tools. I can have the Program Manager of those features give an overview if there is an interest.
As I said, I have some flexibility to make rapid changes to the current Monitoring Module based on requests from customers like you. We still go through the design and code review process but do so as effectively as possible. I’ll go through Michael’s list and get the facts out there and maybe get some opinions on how we can make it better:
There is no hard coded data point limit for monitor collections. Actually, if you were to look at the tables in the database you would see dozens of monitor and SNMP logs differentiated by the date (i.e. monitorCounterLog11032008). The number of tables is based on how many days of monitor logs the Administrator wants to keep for reporting. To ensure performance (SQL Server either inserts or reads/deletes well, not both), we created this table partition logic that you would also see on other large volume systems (I implemented the design for a Credit Card Authorization tool doing millions of writes and verifications a day; and storing them for reporting for 1 year); as the day rolls over, a new table is created and that days monitor log transactions are put into that file. This a couple things:
Allows archival to be very fast. If you want to archive after 180 days, the system can Bulk Copy the records on the 181st day and then just drop the table instead of trying to delete from it.
A majority of the reporting will go against tables that are not incurring insert overhead; again improving performance
Yes, the display of the View Logs feature is limited to the last 2000 data points (it is not hard coded and can be changed, advised against). If the Administrator wants anything more than the most recent 2000 data points, Reporting from the Logs records should be used; there is no limit there; it will report on as much data as you have chosen to collect. (from point 1)
Michael, great point on potentially using RRD, which is great for logs (not designed for referential data such as scripts run in response to the alarm, emails sent, etc.). So I am sure we will continue to use an RDBMS for all the other amplification data in Kaseya. It is now in the Advanced Monitoring design to use RRD (or a competing technology that looks very cool) for all the monitoring logs and the RDBMS for all the relational data. I can also say that the Advanced Monitoring team is integrating in the top Open Source monitoring and security solutions into the new feature. This will allow even more data and the capability to correlate the data. I will have the Program Manager of that team weigh in here if that is of interest.
Alerts when the Alarm transitions out of alarm state is in the system now and as of version 5.1 it is the default condition. It is merely a flag set in the XML file on the agent telling the system to do something called ‘reverse notification’ (and yes that is a weird term for that feature.)
I really like Michael’s idea of have a services ‘dashlet’ that will show an icon of the current ‘known state’ of a service on an agent. I will add that in the next version release.
The performance of the SNMPGet command that we use (part of the NETSnmp open source) can spike the CPU to 100%. Most successful MSP’s that I work with dedicate an Agent box to do SNMP monitoring since they are monitoring thousands of devices. If it is not a dedicated box, our Support team (or via a fairly simple update to the Users table) reduce the number of SNMP worker threads down to 5 (default is 50) to keep the behavior Michael describes from happening.
I am currently testing changes to the SNMPGet command that increase performance (decrease cpu footprint); I have it on a half dozen customers systems and it is working very well. I agree with Michael that we should create an interval to the SNMPGet execution (there is no interval setting in the open source command itself) to give the Admin another attribute to manage the heavy lifting of the Lan Watch/SNMP Agent machine. That feature is being worked on now; I do not know if it will make it in to the next release (I will keep tabs on that and let anyone who is interested know).
Some other items to note:
Kaseya did not release with a library of SNMP Sets and frankly the exercise for an Administrator to create and share those sets are just too hard. The next version of the Monitoring Module (out in a few months) has hundreds of SNMP Sets for every device that we have run into so far. I have been releasing subsets of the SNMP Sets that have been tested if there is interest.
SNMPTraps will also be supported in the next release. Although many of you have figured out that we shipped the SNMPTrap daemon and created your own solution; there are white papers that MSPs are sharing on that. The upcoming release will not break any of the independent SNMPTrap implementations.
I am open to any additional suggestions; I will also have training set up another Monitoring ‘Tech Jam’ and host myself so we can have an interactive session on this topic.
The text cut and paste lost all formating. Little hard to read. Sorry
hi corey,
im curious as to why an external snmpget binary continues to be used by the kaseya agent. from what i can tell (and from my experience with nagiospluginsnt), this is the main cause of the snmp performance issues. i’ve been harping on this fact since 2007 ( http://forum.kaseya.com/showthread.php?t=6843 ), but nobody at kaseya seems to want to address this point. the addition of a polling interval would help a lot, but i really see this as a temporary stopgap measure rather than a permanent solution.
since joining the influencer committee, i’ve been leaving all of my suggestions in the forums. if you’re interested, i started a thread a while back on the topic of current problems with the monitoring dashboard:
http://forum.kaseya.com/showthread.php?t=7491
I’ve noticed that many of these posts are old. Kaseya released an updated version of KES (Anti-virus) & BUDR in December. The new version of BUDR fixes the Acronis flaw on exchange and KES has integrated the AVG 8.0 engine which is a significant improvement over 7.5. In fact, it has less than 1/2 the footprint of the previous version. With respect to Remote Control the most important thing is that it is rock solid and works six sigma. I’ve found that the performance is really dependent on your internet connection and even over a cable modem I’ve never had a problem.
Read thru the whole lot. Interesting..
However, where are we today ???
Have the issues been addressed with Kaseya’s latest release???
It would be nice to know….
We have been using KES for a year now and what a nightmare to deal with them. Some of the issues above we have experienced as well. The worst is their tech support and we have been hosed on that deal. When we dealt with them and had issues the salesperson got some higher level execs on the phone and they basically said that there was nothing wrong with Kaseya tech support and passed the blame back my way. What an absolute joke. We were oversold in the beginning and then switched to a 100 node license and they kept our overage payments in excess of $5k. We have switched to Level and are completely happy with their service and pricing. Run from Kaseya…fast.
I am furious with thier tech support. If I ran the same type of support for my business I would be out of business. It’s really hard for me to sell my managed services knowing when something goes wrong I will not be able to get support of if I do, it won’t be for some time.