I am wondering is anyone else having an issue where they log a EventID and it Truncates the message that is being sent.
I have been told that there is a max character count of 1000 which can be logged into kaseya.
Does anyone else think that this is a flaw within the VSA where you can only update a table within the SQL DB with 1000 characters as some Event ID's are longer than 1000 characters.
I've never had an issue with the limitation. It might be related to how we are using it.
First, to clarify some definitions. The Event ID is an integer in the OS, so even if Kaseya is storing it as a varchar/string it would never be over 1000 characters.
The Event Source could be over 1000 characters, but I've never seen it and it is a bad idea to make it more than a short phrase.
The Event Message is most likely what you are referring to, the body of an Event.
Now this goes back to how we use it. We don't troubleshoot event alerts from Kaseya. We use Kaseya to monitor them, but once we get an alert we normally do all troubleshooting on the endpoint itself via KLC or KRC. In 99% of cases, the combination of the Log Name (Application, System, etc), Event ID, and Event Source are enough to uniquely identify an Event you want to alert on. In that 1% where that isn't true, I can't imagine the distinct part of the Message isn't in the first 1000 characters.
We have >20k endpoints. If we tried to pull back the entire event log, our database would be too big. We really made an effort to minimize the data we are pulling back from endpoints to what is actually actionable. We now only pull the event logs on items we generate alerts on and we've really minimized the alerts we generate to what really is actionable.
After I wrote that I realized I don't think we actually pull back any event logs anymore. In a very old version of Kaseya you had to pull them back to alert on them, but that changed a long time ago. I can't think of a reason we would want the event logs in our Kaseya database. If we are troubleshooting an endpoint, we would look at that specific endpoint. If we are looking for a widespread issue, we would monitor for the specific event and use our tickets to make the correlation.
We don't pull back all the event Logs either but what the issue is that within the service desk in Kaseya it only allowed 993 characters of the Event Log. When I looked on the server itself then I could see more information within the Event viewer. Most people would just investigate from the endpoint but we have a few users who take what is from within the ticket (auto-logged) into the PSA as what is the issue and don't use the KLC only when they really have to.
I know most people use the KLC to investigate but these users like to investigate without logging into the Endpoint.
Ah, got it. We don't use the Service Desk, so our alerts include the full text. I now understand your issue.
I don't know what options are available in Service Desk but, as a manager and developer, I would handle it one of two ways depending on my willingness to invest time.
First, training the staff and letting them know this is the limitation and how to work around it.
Second, execute an Agent Procedure on either the alert detection, which I know is possible, or the ticket creation, which I'm unfamiliar with in this case. The Agent Procedure could get the full text of the alert, split it into 900 character sections, and add them as individual notes to the ticket. This is assuming the Service Desk ticket allows multiple notes per ticket.
The one thing I've learned over years of Kaseya use, don't wait for Kaseya to fix something. That may be a long wait.