Kaseya 2: What’s the Early Buzz?
During the Channel Happy Hour podcast — hosted by Gerard Kane and Brett Martin — last night, I was asked about initial MSP reaction to the recent Kaseya 2 platform launch. I certainly have some thoughts on the matter. Kane and Chuck Lennon (president of TeamLogic IT) also shared some initial reaction on the Kaseya launch. Here’s some perspective…
First, some background: After a few delays in 2009, Kaseya 2 debuted in February 2010. The software architecture is available in various on-premises and SaaS configurations. Instead of offering Kaseya 2 to all of its partners from day one, Kaseya Executive VP Jim Alves told me in January that the rollout would occur incrementally — in order to minimize potential support issues and really scale effectively. As part of the strategy, Kaseya also launched a global SaaS partner program in February 2010.
Early Kaseya 2 adopters include base 2 ICT Managed Services of Auckland, New Zealand. According to a prepared statement from Greg Sharp, managing director at the MSP: “Our engineers gave Kaseya their thumbs up, so it was an easy choice.” Within 48 hours, base 2 rolled out the Kaseya agents to its entire customer base, effectively enabling remote support, patch management, policy enforcement, and ticketing, Sharp added.
But are other MSPs — and existing Kaseya customers — jumping on the Kaseya 2 bandwagon? I’ve got an email into Kaseya seeking an update from the company.
Chatter Elsewhere
Meanwhile, some questions are starting to emerge. During the Channel Happy Hour podcast last night, MSP Services Network (MSPSN) President Gerard Kane and TeamLogic IT President Chuck Lennon shared some additional thoughts on the Kaseya 2 launch.
In recent weeks, MSPSN has heard from several European MSPs that run Kaseya but are seeking alternatives amid the launch of Kaseya 2, Kane said. Meanwhile, Lennon said he wishes the media would take a closer look at Kaseya’s strategy — particularly the company’s pricing model for Kaseya 2.
Some pricing concerns apparently did pop up in Australia — but a media report there seem to be based on miscommunication between Ingram Micro Australia (a Kaseya SaaS partner) and VARs, rather than any factual problems with Kaseya pricing.
If Kaseya partners truly have issues with Kaseya 2 pricing (SaaS vs. on-premises), I’ve yet to hear them — but I’m all ears.
Elsewhere, managed services coach Stewart Selbst has indicated on FaceBook that some Kaseya customers are making the move to LabTech Software, a remote monitoring and management tool backed by ConnectWise Capital. I’m checking in with LabTech to see if they are witnessing any defections from Kaseya to LabTech.
Bottom Line
Whenever a software company launches a new product or service upgrade, customers reach an inflection point. They either (A) stay with what they’ve got (B) upgrade — (C) or move to another platform. Translation: Product upgrade cycles force decision points. And plenty of MSPs are evaluating their strategies right now — especially amid recent upgrades from Kaseya, Level Platforms, N-able and itControl Suite (keep an eye on CAKE), among other options.
In the meantime, I’m checking in with Kaseya for a status update on Kaseya 2:
- How are early rollouts going — both on-premises and SaaS?
- What’s been the MSP reaction?
- What tweaks can we expect in the next few weeks and months?
I’ll be back with updates as I receive them. In the meantime, Kaseya 2 beta testers and early adopters are welcome to contact me with their thoughts (joe [at] NineLivesMediaInc.com).
Sign up for MSPmentor’s weekly Enewsletter, Webcasts and Resource Center. And follow us via RSS; Facebook; Identi.ca; and Twitter. Plus, check out more MSP voices at www.MSPtweet.com.
Related
-
SyncroMSP: Vendors Must Also Evolve from Break-Fix to Managed Services
-
Dataprise CEO David Eisner Named MSP 501 Lifetime Achievement Award Winner for 2018
-
Real Women in Tech: 'You Can Have It All, Just Not All at Once,' Says Questback's Carol Lee Anderson
-
'PR' Doesn't Mean 'Press Release,' Plus Other Tips from a Media Relations Specialist
Our K2 experience has been horrible. The incremental addition of features and redesign of the interface to me has been akin to the move from Windows XP to Vista – more clicks for the same old tricks.
In fact, on a post on the Connectwise forums, I called the K2 update “lipstick on a pig”.
Somehow this has stuck, and there is a new MSP community of Kaseya ex-patriots sprouting up – check it out at http://lipstickonapig.ning.com
In Liberty,
Ben
Joe,
I do want to let your readers know that I have had 4 of my coaching partners recently leave their investment in Kaseya and move to LabTech.
Another tool that I hear about getting many high regards and substantial looks by the MSP Community is PacketTrap, recently purchased by Quest Software. PacketTrap was involved with my Spring Training for Business event. On April 13 I will be hosting a webinar demo of PacketTrap.
I have been a fan and advocate for Kaseya over the years, but I am seeing and hearing that the tools like LabTech, PacketTrap, IT Control Suite and even GFI (Hound Dog) are beginning to put a lot of pressure on the long time industry leader Kaseya.
I would like to see how this whole thing with the different RMM tools plays out.
Take care,
Stuart Selbst
Stuart Selbst Consulting
http://www.stuartselbst.com
K2 is a nightmare. Crashes IE like crazy. They say use Mozilla Crashes Mozilla. Things that were 2nd nature now take for ever. Half then time it is a chore to just get to clients desktop. Above being said I am all for development of product and bugs that need to be fixed. My major frustration is there support sucks. Overseas based and I have tickets that are almost 2 months old that say your ticket has been escalated. For a week we couldn’t even get into clients desktops. Granite it was a firewall issue that in essence took 1 minute to fix. It took a week to get someone on the phone from the USA who was helpful and it took us all of 5 minutes to figure it out. For a company that writes support software they have the worst support. Granite is has always been bad it is just now I need it and I have given up. Still using it but looking at Labtec. My sales rep even told me he is tryign and does not know what else to do to help me. Been a Kaseya customer for 5 years and use to love the product.
So I was instructed to use an IE tab in Chrome to prevent browser timeout loops. ummm, no.
Ben, John: I am speaking with Kaseya the week of April 5 and will ask for some updates on Kaseya 2. Sorry I didn’t do it sooner due to business travel.
-jp
K2 does not work.
Remote Desktop requires high bandwidth and it works almost reliably only in a LAN environment. Issues such as not being able to remote access a workstation is the minimum. The whole user interface is extremely slow even with a very low number of clients and 2 dedicated servers quad processors and tons of RAM.
LiveConnect just does not connect (problem on Relay, 2 minutes minimum time to wait before the system connects and if/when it does, the performances are 10+ times lower than anything else on the market).
The procedure editor will get on your nerves.
User must stick to K1 forever as it does not look like the system is going to be fixed any time soon.
Many people are ditching the product, we are about to do the same. I hear Labtech quite often as the product that can save Kaseya customers from going back to the stone age.
Our migration to K2 has been a disaster also. We support over 2000 devices and have been using Kaseya for several years, so as you can imagine we had a lot of custom scripts, monitoring sets and custom reports. After the migration, we’ve lost ALL of these customizations. After creating a ticket weeks ago, and making regular complaints to our rep, we get a ticket update saying “as I haven’t heard from you, we’ll close the ticket”. Remarkable!
I didn’t think I’d ever say this, as I’ve been a ‘raving fan’ of Kaseya, but now – I doubt very much we’ll be using Kaseya in 6 months time.
Joe – don’t hesitate to contact me if you want to get the first hand experience of a K2 customer. I have everything documented, so you’ll see for yourself that I’m not just ‘mouthing off’ without just cause.
Martin: I respect the fact you’re willing to go on the record. I am at Cisco Partner Summit but will ping you, and I’ll certainly check in with Kaseya. We strive to always deliver both sides of the story. Some MSPs are checking in with me to say they’re having success with K2. Others are sending me private notes indicating that they’ve hit bumps. I’ll strive to bring some order to the discussion in the days ahead.
-jp
Being new to PacketTrap I was pretty disappointed to see that a system belongs to a single policy. I did not gather that from the demo, where I was shown how you can make all the custom policies you need.
Being a former and current Zabbix admin, I am used to creating policies specific to the functionality to be monitored and then adding/removing systems to/from the applicable policies.
For example: I would have a Server 2003 policy, Server 2008 policy, Exchange policy, SQL policy, BackupExec policy, IIS policy etc. If I had a server running 2003, SQL and Exchange, I would apply those policies, and not only could I see by viewing the monitored systems’ associated policies, what the primary roles of the system were, I could easily add and remove the custom monitoring, alerts, etc, by removing it from a particular policy.
So if I move BackupExec to another system, I simply add the BE policy to that system, and remove it from the former. The system policy is the sum of applied policies. Its fast, simple, versatile, and maybe most importantly, intuitive.
It seems like with the ability to apply only one policy, you have to create a unique policy for every possible combination of monitoring and alerting you want to perform, reinventing the wheel every time you do so.
In the previous example I would need a “Svr2003, SQL, BE, IIS” policy, and when I moved the Backup Exec to another system, I would have to create a totally new policy called something like “Svr2003, SQL, BE”, and then fix/modify/rename the old one (to keep monitoring it), or create a totally new one.
It seems rare that a system is totally identical to another and that you would want the exact same “global” type policy applied to it. Also with such a crazy naming scheme it would be hard to find and apply exactly what you are looking for.
If I have 20 servers at a site it is doubtful they are all doing the same thing or should be monitored the same, and that I am likely to need almost 20 separate policies to handle the uniqueness of each system, rather then just a policy called “Servers”.
To expand on my previous post about the how unintuitive and unwieldy PacketTrap Policies are, and how the inherit design makes managing policies across multiple organizations extremely hard for the PacketTrap administrator, I was quite floored today to find out a simple but missing log filter is going to make my life yet harder still. (Thanks Guys!)
So I am configuring Windows Event log alerts I think “hey this is great!” When an event happens I will be alerted, and I can proactively react, which is what I paid thousands of dollars to be able to do, and what I sell to my customers.
Of course after I setup the alert, I quickly found that I was getting the occasional unwanted alerts. This is a problem, since being alerted with stuff you don’t care about is almost as bad as not knowing at all. “No problem” I think to myself, as I go into the management console to begin filtering them out. ”Hmm, I don’t see any way to do that… nothing in the manual… odd”.
So I email support because, I think “surely I don’t have to set down and try to pre-configure each and every single possible alert that I could ever possibly need to be alerted to manually”. I mean that’s just ridiculous. Besides, how could I, or anyone for that matter know, what all those are? They are dynamic, ever expanding, and many times you don’t know about them, until they happen.
Well after talking to the support person, I was told this would be a feature request. A FEATURE REQUEST! THIS PRODUCT IS 24 YEARS OLD! After picking myself up off the floor, I began to come to the realization of what I am getting myself into with product, and I am not too excited about it. I mean I am very new to this and already I am finding it incredibly tedious. That’s right PacketTrap, your advertisements and demos leave that part out, and make claims to the contrary.
I also found out from on the support call, that I am the only person who has ever asked to do this. That’s right, 24 years, and I am the only person to say “where the simple little text based filter to let me weed out unwanted alerts”.
So to summarize.. Say.. you want to be alerted to a Windows System Event of type “error”, but you don’t want to see a handful of repeating errors like “no printer driver”), because you don’t care about those. All you have to do is set down and define a specific alert for every possible windows system error alert that you do want to be notified of. The good news is that, when you’re done doing that, which I suspect you never will be, then you can start on all the other logs and their various types, and begin building each and every one of those alerts as well.
Of course, to be fair, there are three other options. You could not be alerted, and you could be alerted to everything. But then why would you need Packetrap. There are plenty of free utilities that email every event to you, and you could use those.
The third option which I suspect, is what everyone else is doing, is to define what you know, and then add as you discover more. Awesome! I think I just discovered “reactive proactive management”.
Well I guess I will get started. Hopefully, it won’t take 24 years to define all the event alerts that I don’t know I need to be alerted to yet. Besides, if I ever do get them all defined, then I can start trying to replicate them across all those isolated policies.