With the statement that Kaseya is our automation, your liberation I would love to see Kaseya providing procedures that keep our customers applications up to date.vs us paying nineite to do it or relying on each other to create scripts.
In my mind, I fully expect that Kaseya should be using Kaseya internally and their internal staff should have the absolutely best scripters inhouse. Along with that assumption I also expect that they all use the same common applications the rest of us do like Adobe, Flash, Java, firefox, chrome, etc.
In reality there should be a download repository available where there is a different version of the script saved for each verion of the applications saved
ie...under a JAVA heading we should be able to go look and see a different script for each release of jave (1.62.15, 1.62.16,1.7.0,etc)
There shouldn't be any need of Kaseya's customers all needing to fumble though this each month when all I should have to do is download the newest java script, overwrite my existing script and voila, next run cycle, everyone gets the new version.
Afterall its not really called "your automation" if its all our coding doing it....
My guess is that in stead of all sorts of procedures, Kaseya uses their own KSDU (Kaseya Software Deployment and Update).
I also think that because it was clear that all these procedures had to be rewritten for a new version of a specific application (java, adobe reader, flash, putty, whatever) one of the procedure writers had an epiphany when finding Ninite and how this works.
He then decided to inform his manager about Ninite and how to integrate this with kaseya, which sounded like a plan.
A list of simple questions:
Which is cheaper? (My personal thought is the latter, because you can now have your Kaseya admin also look toward other things to improve). Collect the data, run to your CFO (or whoever is in charge of the finance department) explain your excel sheet and I bet you'll have a signature for buying KSDU within 2 days.
if you don;t know what KSDU is, check the webinar video.
My biggest problem with KDSU is the price. Ninite is around $.50/machine/month in my research. KDSU is over a dollar. That is a lot of mark up.
There are a bunch of new Agent Procedures coming out with 6.3, that will give more install/update procedures, however it is not Kaseya's intention to use the Agent Procedures to manage every version of every install for every product, which is why we released KSDU.
The whole point of KSDU was to solve this issue for once and for all. KSDU not only installs these products in a completely automated way, it monitors the versions and can automatically update them to the versions you want, giving you a much better methodology to manage version control.
Although KSDU does have the Ninite engine in it, it does far more than Ninite does on its own, it provides multi-site management and also uses our own technology to manage the entire process, so when you buy KSDU you are not just buying Ninite. For example we expand the ninite concept of a library of versions to go as far back as you'd like providing full version control, which Ninite does not, this allows you to do things like create packages by department/site/customer with specific versions for them for compliance, compatibility etc. Very useful when you get that one application that needs a specific version of Adobe Reader, or a specific browser version to work. And of course, all of this type of thing is far more complex logic than you'd want to try and manage in Agent Procedures.
Feedback from our customers that use KSDU has been fantastic, and all reports I have heard is that it saves far more time, effort and energy than it costs to run buy a _huge_ margin. It really solves this issue and means those customers that are using it never think about this subject again. They get back to managing a few exceptions rather than having to deal with this themselves.
If you script it right you can do it without having to do any major updates or script rewrites. A few years ago an awesome guy at Kaseya (Ben) gave us the foundation of how we could do this ourselves. I made my own improvements on the concept and I now have a generic deployment script template set that can audit, install and uninstall most common apps and the rest with only minor changes to the template scripts. The most of my time wasted with this method is testing it on multiple platforms to ensure that it works after I updated the metadata for an installer, but I suspect this is an issue you would face when using KSDU too.
I really like the idea of ninite and it is very basic if you purchase it., but it is very much just running command line options which are easy to do with Kaseya.
I also agree that the Kaseya integration adds alot of value...however Its really hard to justify the cost increase from 185/month for 1000 agents to $830/month....if it were something like $300 per month I'd be all over that.
As it is, I can update Java, flash and firefox and chrome with a few procedures...not as easy, but its a matter of logging in and updating a provedure once every month or so.
Hardknox - the Ninite guys do an outstanding job of updating their audit process and silent application deployment EXEs to support multiple platforms and languages.
I know quite well what Ninite is doing because I did the same thing for a few years, albeit with a much more limited set of apps and only a focus on English-based installers. With a genuine recognition and understanding of the value they provide, it was clear they would be excellent to partner with as a software catalog provider for KSDU.
Your time should ideally be valuable enough to justify using KSDU instead of using scripts. We took a set of functionality that could be technically done with procedures with lot of time and elbow grease and centralized it into a module complete with a dashboard, alerting, policy-driven management, automated use of remote file sources, etc.... a pretty good summation can be found on the product page.
KSDU 1.1 will be coming soon with a set of enhancements based on feedback received and the internal roadmap we have for it's progress (I'll wait for our product marketing team to mention the official details).
If you really wanted to, you could deploy all your Microsoft updates with agent procedures and not even use Patch Management. You could put together your own routine for interacting with the Windows update agent, detecting missing updates, downloading them, etc.
Ultimately that's only a tiny fraction of what the Patch module provides and I can't imagine anyone actually going that route. I hope the same sentiment will be shared in regard to third party application deployment/updating via KSDU -- I think you all can recognize the increasing amount of press generated with each Adobe and Java 0-day exploit (seems to be one comes about every other week), elevating the importance of automatically updating them similar to the way you deploy critical Windows Security patches instead of fiddling with procedures and trying to piecemeal together reports with Script Logs to verify your agents are updated.
For the record, last week's Java exploit was available in KSDU's catalog the day it was posted by Oracle, and if you had a KSDU policy setup to update Java you wouldn't have had to lift a finger to make sure your machines had it :)
Another note - with 6.3's upcoming modular reporting capability, you should be able to generate some pretty compelling 'executive summary' reports to include KSDU statistics, similar to what you get with the Patch subsection of the Executive Summary report in 6.2 today.
Automatically updating can be just as dangerous as not updating, the only way to mitigate this danger is to test the updates first. I ran into this issue many times with the Java Runtime Environment breaking access to web based applications.
What about some very simple aggregate table reports showing the the machine names and the application versions. Sometimes just updating is not enough and what you really need is alerting and reporting methods to show and sell your/our services.
My new audit procedures using custom fields can tell me if MS Dynamics AX, CRM and MS Communicator/Lync clients are up to date by checking the current version and matching it against a list of Rollups and Cumulative Updates. Same with my AV audit scripts that can not just tell me the version of the client but also if the virus definitions are older then 5 days. The point I'm trying to make is if these type of abilities do not exist then I have to go through the whole Feature Request process to get it added and this only sometimes happen if enough other Kaseya customers makes the same request. This waiting process can sometimes take so long that its easier for us to just develop our own solution that we have more control over and for many of us there is no other option then shop around for a solution that can do what we need.
I have many reservations about KSDU, some I will admit might be unfounded and other are derived from past experiences with the limitations of other modules. Another is the fact that many of the functionality to audit, report and update applications are already available in the Kaseya Core but for one reason or another these features never really reach their full potential.
Anyways I will evaluate KSDU after 6.3 is released to get a better understanding of what its advantages and limitations are.
KSDU allows you to configure on a per-app basis whether or not you want to update to the latest version automatically, or lock it to a particular version and get alerts when a new version is available. This was extremely important and it's a feature you get with KSDU that you won't get with Ninite alone.
Exactly what choices you make depend on the application in question and how it affects the systems you're charged with maintaining. Nothing much different here compared with Patch Management practices which differ between our customers -- there is no "right" answer in how you setup your update policies.
The KSDU catalog is intended to consolidate all of the metadata that you would otherwise need to bury within agent procedures and give you a central location to deploy or remove applications (yes, uninstall strings are coming to the catalog in 1.1).
The actual IF checks you perform in a procedure to look for a particular application version by auditing a file or checking a registry key to see if it exists or contains a version string can be entered in a simple manner in a catalog entry. The Ninite catalog is a little unique and doesn't expose this data as it's part of what they are delivering, but you're free to create catalog entries on your own to deploy software just the same as you would an agent procedure, only in a much more effortless manner.
Once you check out KSDU with 6.3, if there are features it is lacking, please do submit a Feature Request and if you want to, reply right back here to the Community with the details. I wouldn't necessarily expect you to replace the entire scheme you currently have in place for deploying applications overnight and I know it takes some time to describe what is missing, but your experiences and inputs will be appreciated and reflected back in the product.