Kaseya Community

Anyone have Monitor sets we can import? ;)

  • Hey everyone,

    We are making another attempt at getting our monitor sets going and notice that the 'Standard solution pack' from Kaseya, well, it kindof sucks. Does anyone have a group of monitor sets that they utilize for SMB business that they have tweaked and are effective that we would be able to import? Our AV is Symantec.cloud. We are trying to prevent reinventing the wheel if someone has already done it!

    Thanks,


    AB

  • I too would be very interested. This is one thing that Kaseya should really put some serious effort into. A standard default set for each module that is tested to work and is maintained by Kaseya would be of huge benefit.

  • We have a few monitor sets on our ClubMSP site, but we need to add more.     The biggest issue with monitor sets is the amount of noise they can generate.   Any default monitor set is going to need tweaking for your environment.    Settings that work for an Enterprise client, are useless for a SMB client, and vice-versa.  

    In our MSP practice, we are mostly concerned with running out of disk space.    For a few larger clients we add Exchange and SQL monitors, and in a few rare cases we have monitored specific services or a process.  IMHO more monitoring is not needed at this level, unless you suspect a problem.

    My usual question when partners ask me for monitor sets is "What do you want to monitor?".   Let us know, and maybe we can give you some guidance...

  • Here's the rub,

    Kaseya, out-of-the-box, is nothing more than an empty shell. A framework, if you like, into which you build your own scripts, monitor sets, policies, reports, etc. etc. as you see fit and in a way that suits your clients.

    Yes the system comes with a smattering of pre-built examples, however most are dated [most were developed in the Windows XP/Server 2003 era and untouched since) and/or so generic as to be almost worthless.

    There have been some attempts to improve this e.g. the "standard solution pack" and "service desk" however they are a token effort at best, hard to expand on or customize, and once again never updated. Also, we all know that in IT, there's no such thing as a "standard", so it's actually very, very difficult to build a generic script that works for every circumstance, or even the majority of them.

    Also as K has evolved, these haven't kept up. e.g. KNMi should replace classic monitor, but a lot of things are still built around classic monitoring; service desk should replace ticketing, time tracking, alerts, alarms etc. but really doesn't, so now you have a mix of 'older' and 'newer' frameworks, but nothing drawing everything together into a single, workable solution.

    No two K admins will probably build their setup the same way, and each will no doubt tailor their setup to suit circumstance; nobody wants to spend the time making a perfect, generic script that works for everyone (just look at hard coded folder names, email addresses, custom fields, (lack of) 32+64 bit support, etc. etc. as seen in any posted script)  and you know that to use it on your system you'll need to edit the heck out of it first.

    Also, because we admins have to invest massive time and effort developing these scripts, they are seen as the Intellectual Property of our business, and so we are somewhat reticent to share our hard work with others.

    So, where to from here?

    We can continue to discuss our scripts and post code snippets, and that's fine. But what's really needed is a re-definition of what the Kaseya framework really is (i.e. omitting the legacy sections), and how it should be used (i.e. forget monitoring, time tracking, ticketing, alarms and alerts for starters, adopt policies instead of hand-set settings, use ORGs and Roles, not machine groups, etc.) and THEN build a whole new category of scripts that are built around modern conventions e.g. no support for older than server 2008R2/Win7, powershell where possible, full support of "2012+" products, code written as generically as possible e.g. use of variables not hard coded paths/filenames, no assumptions e.g. c: drive holds the OS, 32/64 bit support across the board, etc. etc.

    The problem of course, is that this is a MASSIVE amount of work. And I am willing to bet that nobody is prepared to do that work - so instead we have the hodge podge of  bits and pieces that Kaseya has grown into organically over the last 10 or so years.

    Frankly, I'd rather see a K3 re-write with all the legacy crap omitted and a clean start using only the "right" ways e.g. KNMi, policy config, scripting engine done over and service desk+standard solution pack overhauled to just plug into powershell. But that's dreaming. Should I start my own MSP package ;)