Kaseya Community

Kaseya Agent Event 5024 Overflow detected

  • We use kaseya almost a year now and have about 750 different machines in our system. And the more systems that come into our system the bigger the following problem gets:

    When the Kaseya agent detects that thare have been to many event logs within a short period of time it completly stops collecting eventlog for the machine. I understand that this is some kind of flood protection, but is it posible to auto reset the logging after 5 or 10 minutes?


    Legacy Forum Name: Kaseya Agent Event 5024 Overflow detected,
    Legacy Posted By Username: lantrust
  • I agree this is a very annoying problem we too have wasted so much time on.. In theory the event logs of a machine should not be generating more events then the overflow value but it just doesn't work like that. We have found there are many false positive situtions that create the overflow intermittenly ondifferent machines.

    In addition to an engineerfollowing up and troubleshootingwhy the server was genrating so many events to hopefully stop it, we alsoassign an engineer 4 times per day to manaully re-enable all event loggging on all servers so ensure that we don't miss any critical events.

    I remember that there was more tips and tricks in this forum about the overflow issue, butthesearch/index functionnever really workedso I can't find any...


    Legacy Forum Name: Server,
    Legacy Posted By Username: cberger
  • Before opening up this net Topic I've tried looking up this problemen in the forum, but also without result.

    Could it be posible to write an autofix script on this problem?


    Legacy Forum Name: Server,
    Legacy Posted By Username: lantrust
  • There is a way to reset the logging automatically. I do it outside of Kaseya, but I could write a script if anyone is interested.

    WARNING: THE ATTACHED PROCEDURE DETAILS MAKING SPECIFIC CHANGES DIRECTLY TO THE KASEYA DATABASE. UNDER NO CIRCUMSTANCES SHOULD YOU PERFORM THIS PROCEDURE ON A PRODUCTION DATABASE WITHOUT FUTHER TESTING IN YOUR ENVIRONMENT. THE AUTHOR OF THIS DOCUMENT TAKES NO RESPONSIBLILTY FOR ANY PROBLEMS CAUSED BY THE FOLLOWING PROCEDURE.

    Basically, when you go the the Agent/Logging screen, you can select the log events that you want to capture for each agent. When you make your selections and click on Update, Kaseya sends these changed settings to the USERS table in the Kaseya ksubscribers database. Along with the setting changes, a bit is turned on (set to 1) on the USERS table in a field named "dofullcheckin". If this bit is turned on, the next time the agent checks in, it will update its configuration with any changes in the USERS table, then Kaseya will set the "dofullcheckin" bit back to 0 (zero).

    The settings for each Event Log that you want to capture is set in theUSERS table in the following fields:

    ntApplicationLog
    ntSystemLog
    ntSecurityLog

    In each of these fields, a number is stored which represents the settings you have selected for logging. The number stored in these fields is calculated as follows:

    Error (E)= 1
    Warning (W) = 2
    Informaiton (I)= 4
    Success (S) = 8
    Failure (F) = 16

    To determine the number stored in these fields, you just sum the values of what log events you are wanting to capture.

    Examples:

    Log all events = 1 + 2 + 4 + 8 + 16 = 31
    Log Errors, Warings, and Failures = 1 + 2 + 16 = 19

    Once you determine your logging, just set these values in their respective fields in the USERS table (ntApplicationLog, ntSystemLog, and ntSecurityLog), set the "dofullcheckin" bit to 1 (one/True) and that's it. The client will perform a full checkin and will update its configuration from the USERS table (Kaseya will automatically reset the "dofullcheckin" bit back to 0).

    You can check that the settings have been applied by viewing the KaseyaD.ini file on the agent in the agent's installation folder.Look for the following entries:

    NT_App_Event_Log 111111
    NT_Sec_Event_Log 111101
    NT_Sys_Event_Log 111111

    The numbers to the right will represent the settings retrieved from the Kaseya database from the USERS table, represented as a binary string. There is no needto change these values in this file, it is overwritten when the agent checks in. The numbers represent a True / False relationship to the logging in the following order:

    EWISF (Error, Warning, Information, Success, Failure), where 1 is True, (collect the log data) and 0 is False (do not collect log data).

    Thanks,

    Greg






    Legacy Forum Name: Server,
    Legacy Posted By Username: gssloan
  • Just for you uber geeks out there the number that is placed in the database tables are actually binary..

    Also be careful doing this since if you modify your database it can potentialy cause major issues.

    God Bless,

    Marty


    Legacy Forum Name: Server,
    Legacy Posted By Username: MissingLink
  • MissingLink wrote:
    Just for you uber geeks out there the number that is placed in the database tables are actually binary..

    Also be careful doing this since if you modify your database it can potentialy cause major issues.

    God Bless,

    Marty



    Your absolutley correct Marty. I modified the post to add a warning message.

    Yes, data stored in the USERS table for the logging fields is an integer type field containing theDecimal representation of a Binary number.

    Thanks,

    Greg



    Legacy Forum Name: Server,
    Legacy Posted By Username: gssloan
  • Well, technically, ALL numbers stored in a digital computer are stored in binary. They can be REPRESENTED in different ways - as decimal numbers, as integers, as octal, as hexadecimal, etc.

    I think what you REALLY mean is that they're bit-wise encoding, meaning that each bit stands for something. They're also known as "flags."

    But in any case, I must say that information is very much appreciated. Now I'm going to have to write a short program to update that database and then see if I can write a script that will trigger that based on the overflow errors - or it could just work on a timer, but that would probably mean a much greater lag in resetting.

    Thanks again.


    Legacy Forum Name: Server,
    Legacy Posted By Username: warever
  • Heres a little tip:

    You can do this in a script from Kaseya. Setting these values. Just look around a little and you will see how.

    God Bless,

    Marty


    Legacy Forum Name: Server,
    Legacy Posted By Username: MissingLink
  • warever wrote:
    Well, technically, ALL numbers stored in a digital computer are stored in binary. They can be REPRESENTED in different ways - as decimal numbers, as integers, as octal, as hexadecimal, etc.

    I think what you REALLY mean is that they're bit-wise encoding, meaning that each bit stands for something. They're also known as "flags."

    But in any case, I must say that information is very much appreciated. Now I'm going to have to write a short program to update that database and then see if I can write a script that will trigger that based on the overflow errors - or it could just work on a timer, but that would probably mean a much greater lag in resetting.

    Thanks again.



    Thanks for the feedback. As far as a program, depending on your needs, you wouldn't need a program IF you just wanted to set any of these fields to a fixed value for all machines.You could just execute a Kaseya script on the Kaseya Server thatexecuted theSQL command line OSQL command,passingwith it a T-SQL Update Statement. Depending on your version of SQL and your authentication settings within SQL, you could issue the following command on your Kaseya SQL Server:

    OSQL -d ksubscribers -E -Q "UPDATE ksubscribers.dbo.USERS SET ntSecurityLog = 23, dofullcheckin = 1 WHERE (ntSecurityLog <> 23) AND (dofullcheckin <> 1)"

    The above would set the value of the ntSecurityLog field to 23 (Log EWIF, No (S)-Success) for ANY Machine that did not have the ntSecurityLog field value of 23. So if most of you machines are already set to this value, the above command will only be processed on the machines that did not have this value set, making for what should be a very fast execution of the command.

    The above command line assumes a Trusted Connection (-E).

    As far as scheduling it, it depends on the amount of changes you would be making. Using the above command scheduled on a periodic basis, it would execute quickly.

    As far as using an event set, obviously you could create an event set that looked for "Overflow detected" (See below) and assign this to your machines and trigger a script specific for that machine to run. You could use an OSQL command similar to the above, but passing to it avariable from Kaseya to use in the WHERE portion of the T-SQL command (i.e. where the Kaseya Variable Group.Machine ID = the emailAddr field in the USER table).

    Edit: If you do schedule the script to run based on the "Overflow detected", I would schedule it to run 15 minutes or more AFTER the event occurred, just to eliminate a truely chatty event log.











    Once again:

    WARNING: THE ATTACHED PROCEDURE DETAILS MAKING SPECIFIC CHANGES DIRECTLY TO THE KASEYA DATABASE. UNDER NO CIRCUMSTANCES SHOULD YOU PERFORM THIS PROCEDURE ON A PRODUCTION DATABASE WITHOUT FUTHER TESTING IN YOUR ENVIRONMENT. THE AUTHOR OF THIS DOCUMENT TAKES NO RESPONSIBLILTY FOR ANY PROBLEMS CAUSED BY THE FOLLOWING PROCEDURE.



    Legacy Forum Name: Server,
    Legacy Posted By Username: gssloan
  • I've posted manytimes about the overflow issue. Kaseya had told me they were going to change the location of the event log filtering from the KServer to the local agent in the future. I'm assuming this will happen in V5.0 but I can't be sure.

    So as of Friday afternoon I had resolved that I was going to solve this issuemyself. So you've savedme the time of reviewing the database and breaking down what fields where involved. Thank you.

    Now the only issue is I have some systems with event log montoring and some without. So I'm looking in to writing a program to reset the values to a previously recorded state. This way having various event log settings would be possible.


    Legacy Forum Name: Server,
    Legacy Posted By Username: connectex
  • Wanted to give you a brief update on this issue. In version 4.9, which will be released Q1 2008, there will be unlimited logging. We will also have a function that will archive the logs from the database as well. A pre-release annoucement will be coming out in the next couple weeks to provide an overview of the 4.9 release.


    Legacy Forum Name: Server,
    Legacy Posted By Username: jimalves
  • connectex wrote:
    I've posted manytimes about the overflow issue. Kaseya had told me they were going to change the location of the event log filtering from the KServer to the local agent in the future. I'm assuming this will happen in V5.0 but I can't be sure.

    So as of Friday afternoon I had resolved that I was going to solve this issuemyself. So you've savedme the time of reviewing the database and breaking down what fields where involved. Thank you.

    Now the only issue is I have some systems with event log montoring and some without. So I'm looking in to writing a program to reset the values to a previously recorded state. This way having various event log settings would be possible.


    During my research, I couldn't find a location that stored the machines configuration of Event Log settings prior to them being changed because of an Overflow event. That would make thing much easier...

    Greg


    Legacy Forum Name: Server,
    Legacy Posted By Username: gssloan
  • See, that's the programmer nerd in me... always thinking of writing something as an EXE rather than just using an existing command line utility.

    But there is a minor flaw in the way you did it and that's that it expects that all workstations will be configured the same way. In my implementation, that isn't the case - I've got some machines (mainly servers) that freak out if certain types of events are logged (like trying to capture security events on some servers with lots of stations).

    I suppose, though, that if there's some available field like a collection field (not sure whether that's easily linked), the machines could be put into collections and then THAT used in the WHERE part of the statement.

    Then, ANY overflow event (and I've already got sets looking for that) would trigger the "reset them properly" script and SQL command.


    Legacy Forum Name: Server,
    Legacy Posted By Username: warever