I was curious if we are particularly unlucky, if our questions are too complex or if it's really the way it is.
We Love Kaseya, but there is no support whatsoever.
I mean, yes you can create a ticket but in the last years ALL of the tickets or emails we sent ended up resolved by ourselves
or in the VOID.
Every single response we got from support was falling in one of those categories:
- Entirely wrong
- Waste of time
- Ignored for days until we resolve it ourselves or find workaround
In the last ticket I have opened they even asked us money to get it resolved
(We were trying to report a bug.. I would think Kaseya would be interested in that)
Is there any trick to get real support for the product?
Any Saint you need to pray to? may be a secret Email of someone that knows the product?
Wow, that's a very good question - I certainly haven't found support to be so difficult.
I will admit you can be in luck or draw a complete blank on support. But, you should get a reaction that makes sense. It has to be the same day on a critical issue down to less important things taking maybe 3 or 4 days. That's about what we see on average. And if you want to complain about support you can always talk to your Kaseya contact and ask him for some extra attention.
If it's a real bug you reported it would be logical to get a thank you. I know if you have a feature request you want addressed they will quote you how much it would cost to get this done.
Hope you will have better support next time!
Support for us is about 50% helpful and 50% not, depending on the topics, for problems in core functionality they are prompt and can often resolve bugs via updates within a week or two. Third party Modules such as KAV is another story, I don't think the communication between Kaseya and kaspersky labs is great and from what I can tell no special arrangements are made between the companies to expedite patches to resolve critical issues.
We still have about two issues that have not been resolved regarding Kaseya reporting false positives in compress files and often times not updating defs at all. We get the "it's being worked on and a future update will correct the problem" spiel for months on end.
All and all it depends on how you use Kaseya and what issues you are reporting that determine the type of support you will get.
Alessandro Di Marco
Do you actually have a support contact with them? They've never asked for any sort of payment from us, because we pay for our support and maintenance. If you pay for support, I would be shocked that they asked for additional payment (unless they just happened to not do it to me over the last 2 years) and I would call your account manager. If you have had this many problems, I would get your account manager involved and talk about it. If support hasn't resolved even 1 of your issues, then you aren't getting at all what you are paying for. I know getting our account manager involved and having frequent communication with her has helped quite a bit in getting things taken care of for us.
All tickets resolved by yourself though...I thought my luck was bad....
Alessandro Di Marco I just saw that you pay for M&S (sorry for the oversight)
Call your account manager right away.
Nicolas Ponce can you help point our friend in the right direction?
Thanks for your feedback OudjesEric and wellbornsteak,
May be it's the area not well served... (we are in Asia Pacific)..
:-) in my last ticket the support personnel even asked me to point them to the location of the Kaseya Help files... I cried..
Well, my last issue I had was related to 2 LUA functions that don't work (always return empty string).
When you report a LUA issue, you are supposed to get someone that knows what the API is, but apparently no :-)
Thank you OudjesEric Christopher Curtis for helping clarify.
I have already reached out to the support management team to get in contact with Alessandro Di Marco.
Without putting to much information on the community about Alessandro's support ticket, it appears to be a misunderstanding of a professional services request vs. a support requesting with a custom LUA script.
As a previous member of Kaseya Support for a number of years, the policy is to defer custom scripting to Professional Services. Kaseya Support will help debug or troubleshoot custom scripts that have already been developed, but will not build them on their own.
If there is indeed a bug in the product, we will never charge you to report it.
Many community members both on and off this thread have reported product defects or bugs which have been corrected or are planned for correction.
However, the product defect can take support sometime to verify or confirm in certain instances especially when it is a more complex topic.
Alessandro Di Marco - to possibly help get an answer here on your issue - it appears that you're LUA script is leveraging API calls (GetAccountUser() and GetAccountPassword()) from KNM 4.0 standalone documentation:
However, the ticket appears to have the details for your VSA R9.2 which may be using KNM integrated?
I do not want to deviate this thread into a support ticket - but are you using KNM 4.0 standalone or VSA9.2 with KNM integrated?
By all means feel free to deviate :-)
If I get an answer it would be my very first and nothing would make me happier
(I will print it, frame it and put it on the wall in my office)
I am using KNM integrated on 9.2.
GetAccountUser() and GetAccountPassword() do not seem to work unless I am missing something.
My understanding is that the KNM monitor provides the ability to pass specific credentials to the LUA Api.
If I have understood how it works, in the Basic TAB of the Monitor, I could go the the Account Settings section, choose the "Use specified credentials in API's" and from there pick up an Account Type that i can then read using the:
GetAccountUser() and GetAccountPassword().
But, no matter what I do, I don't seem to get any value from those functions.
For my latest script I would need a VMWare user (I am doing CIM calls to monitor disk health of my VM Hosts)
In my script if I hardcode the user name and password variables then all works as expected but it defeats the nice KNM mechanism for authentication and it is not secure as passwords are left in clear text on the LUA scripts.
Feel free to ask me any further detail I can provide.
Alessandro Di Marco
My first concern would be that KNM 4.0 standalone is very different architecture opposed to KNM integrated in 9.2 (Standalone instance vs now an integrated instance with different functionality)
Many of the API functionality regarding user and user access was removed as it would allow potential security issues for the entire VSA system.
Looking at the API documentation for 9.2, this API call is no longer listed as available - which is why I believe the support tech did not immediately know the LUA API calls you were referencing (Of course I have the benefit of hindsight and your recent update in the ticket).
Once KNM was integrated, it no longer has independent user logins as standalone did which is what I believe the LUA API is referencing.
I would need to test passing credentials hardcoded, or you could provide me the hardcoded version with the username/pw removed from the script.
My guess would be you are doing something similar to the following:
function main() -- Arguments for query sUser = GetAccountUser() -- are you inserting your VSA username and password manually here? sPass = GetAccountPassword() --sUser = "Your User" --sPass = "Your Password"
Yes, the documentation can be confusing, when you search in google it shows Kaseya 9.1 documentation but it brings you to the version of the Document where those 2 functions existed.
Try a google search with Kaseya LUA API and you'll understand what I mean:
But of course one asks himself then: if those functions have been removed... then what is this thing doing in KNM?
To me this seems what I was looking for and it's a nice functionality because I don't have to hardcode the passwords.
But you are correct.That is exactly what I do in the function (I have to hard-code the passwords).
If you want to have a look at the function (it works on DELL Servers and on any Server that responds to an OMC_Discretesensor CIM Class)
I also attached the function here.
By the way:
The support gave me a call and the last guy who is taking care of my ticket, seems honestly wanting to help.
Considering today is good friday (holiday), at least you get points for that :-)
Thank you for updating me on your status. Glad to hear support gave you a ring and I hope you had a good holiday.
I was able to reproduce your issue using my internal test systems:
Does that look like what you are seeing as I believe this confirms our discussion?
Unfortunately, this feature is not in the documentation for the integrated version and may have been a function only available and supported on the standalone-version.
I see that the support technician assigned to your case did send your ticket request to both the engineering and documentation team.
At this point, I would recommend working around this with the hardcoded values until you get official word.
If I come up with another solution or alternative, I will be sure to add it on to this thread.
Well, just because something is not in the Documentation does not always give for granted the functions do not exists
or have been removed (I also do not see anything in the release notes that suggests the removal of the functionality).
But I know they don't work.. and it is to be seen if this is considered a bug or a loss of (a Good) functionality from previous version.
Also bear in mind that your test may not be conclusive (if you follow the previous version of the documentation, those functions
are NOT supposed to work in the IDE and only work when called from within KNM).
Still the mystery remains on what the "Use specified Authentication for Api" does in the KNM interface but yes,
I am already using the work-around of "hard-coding" the password and wanted to do it the right way
(hence why I created the ticket in the first place)
But you are welcome to propose any alternative way of doing this or at least find out what the
"Use specified Authentication for Api" does (out of curiosity).
Thanks for answering though, you have been way faster than the support ticket and I am wondering if this
should be considered by Clients the best way to get support (or at least an answer) :-)
Hey Alessandro Di Marco
I realize that the IDE will not obtain the user pass from this instance, but I thought it was a better way to demonstrate the issue then showing the same error message in the UI.
The specified feature is documented here, which I am sure you already found (I think you want to know if this feature requires that setting?)
Since I used to be part of the support team, I can confirm that while I can only reproduce - the only way to get a final answer, fix, or resolution to an issue is by working with our support team (Of course that does take time and does not always happen as quickly as we want it).
I did some more looking into this, and it appears that this was no longer documented feature after version 5 of KNM standalone.
KNM 4.1: http://help.kaseya.com/WebHelp/EN/KNM/4010000/API/index.htm?toc.htm?9473.htm#9473.htm
After 4.1 KNM, we released KNM 5 which was beautified and had some changes around the whole standalone product;
I will keep digging see if this turns up any more information.
Yes, that is exactly the documentation for the feature... so.. how this can be usable within the LUA script
accordingly to the documentation to say.. Logon to SSH
without a GetAccountName() or a GetAccountPassword() function inside the script?
What's the point of passing the SSH credential via the KNM interface and then instead
SSHClient = TLuaSSH2Client();
You end up doing
It's completely pointless, hence the documentation is either incorrect or the person that decided to remove those 2 functions did not know what he was doing :-) or failed to provide for a documented alternative.
I bet there's a Product Manager or an Architect around Kaseya that may know the answer.
Honestly, I would be happy with a "whooops" instead of insisting that it's normal because the documentation does not have it :-)
One should ask himself: Regardless if it's in the documentation or not, does it makes sense to pass credential that cannot be used anywhere?
Thank you again for your answers, always appreciated.
By the way: my ticket is SILENT since days... :-)