Kaseya VSA in a nutshell
Rating: 8 out of 10
IncentivizedUse Cases and Deployment Scope
We use Kaseya to automate patch management, audit equipment, and finish systems configs during the build process on all managed systems.
Pros
- Applies specific settings to machines that match certain criteria
- Remotely run scripted procedures against monitored events in system event logs
- Maintains and audit and change records of all devices
- Manages machines across multiple active directory domains
Cons
- Policy application & push. Currently all policies claim to not be current on 1000's of machines, when in fact they are. Re-running policy sync's across all devices daily is a huge tax on the system. Although this is strictly a cosmetic issue, because the policies are in fact correct & current, the dashboard lacks the ability to keep its' records straight. This has been a problem since version 6.
- Live connect. In earlier versions I could customize web links for end users, this feature was removed in 9.0, and has been raised to dev on multiple occasions. Under the current version only a max of 5 links appear, and they are customization by the end user.
- Patch policies need to include a simpler way to exclude patches. Like with WSUS its much simpler to have a policy that denies specific patches rather than creating a policy to allow everything with exceptions. When policies are changed every month with new patch cycles this is hard to manage.
- The Reporting feature lacks an intuitive interface. Its easier to write a query and run it on the back end in Microsoft reporting than use the built-in reporting feature.
- Procedure log interface needs to be created. When writing procedures and then testing them, I have to leave the procedure section and browse logs under audit, then return to procedures.
- Procedures that fail need to have additional logging, there is a lot of guess work when trying to understand why a procedure failed, this could be simplified by passing the powershell or dos failures directly into kaseya, instead of saying this line item failed.
- Procedures that fail under IF then statements, it would be better to state which line item failed when using if then statements instead of saying a script failed at the if then statement and not a line within the if then statement.
Likelihood to Recommend
Since the Kaseya VSA module is very specific in what it covers, this module is well suited for patch management, script automation, third-party updates, and device state statuses. I honestly cannot think of reasons for why it would not be appropriate. It excels at automating scheduled procedures (a lot better than SCCM).
Where Kaseya runs short is in their product support. They lack the understanding of their product, I end up solving most of my problems even after opening tickets. They also like to close tickets that are still in progress, as well as open multiple tickets for the same issue.
Where Kaseya runs short is in their product support. They lack the understanding of their product, I end up solving most of my problems even after opening tickets. They also like to close tickets that are still in progress, as well as open multiple tickets for the same issue.
CJ
Christopher Jon Olesch Jr.
Senior Network Engineer in Engineering at UbiStor Inc (11-50 employees)
Vetted Review
3 years of experience