Jump to content

kingoftheworld

Members
  • Posts

    191
  • Joined

  • Days Won

    1

Posts posted by kingoftheworld

  1. Has anyone experienced an issue in ERA 6.4 where tomcat appears to go unresponsive?  I had one of our IS folks update their Kali VM while their network connection was NAT'ed off of their workstation that has ESET on it.  We have muted the machine, but I am attempting to clear out the threats from the console.  If I select one or just a couple to mark as a resolved, the web interface becomes unresponsive until I restart tomcat.

     

  2. 37 minutes ago, Futura said:

    Yes, I see that, but it would still be nice to be able to retrieve the last few scan logs using the RA rather than having to remote into the computer.  I see that ESET is providing more RMM-type tools as part of the agent, but I'd prefer that you add back the ability to pull scan logs and other Anti-virus tasks first.

    If you're trying to save server resources I understand... the scan logs don't have to be saved for long... I'd be perfectly satisfied with having to run a Get Logs task and then having the log data purged from the server after 48 hours or so.

    Agreed.  Another nice feature of previous ERA products that has been removed.

  3. 3 hours ago, MartinK said:

    Technically it means that database is not able to handle amount of received data. There are multiple possibilities what could be wrong:

    • it may be HW limitation -> write speed is sensitive to DB connection delay (especially if DB is on different machine) and also disk write speed that hosts DB server
    • your AGENTs are sending too much data .. for example automatically collected exported configuration in case computer reported problems could flood server with too much data. Also reporting non-ESET applications may be generating big data sets. We have also seen huge quarantines that overloaded database.
    • pending logs count can be increased during DB cleanups execution, which are executed at 00:00 of SERVER's local time.
    • errors during logs processing (writing into database) may result in overall slowness of processing: any chance your SERVER's trace log is full of DB-related errors?

    Please provide basic statistics of your ERA as in previous posts, especially basic information from status.html and DB table sizes (count of rows). In case value "Received in last hour" in log statistics will show higher number, there should be tool-tip showing more detailed information (not sure whether in your version), which may help us find out what type of logs is causing problems.

    Log processing has been significantly improved for upcoming version (6.5) to be released soon. Most of changes were performance-related.

    Thanks for the reply.  For database specific issues, what should I recommend to our DBA to check for?  SQL isn't showing any errors and there is plenty of available resources on the server.  The database does reside on a separate server from the ERA server. 

    The pending logs don't seem to have any patterns around 00:00 localtime. When I am watching this happen, it appears the ERA server gets roughly 15-16k pending logs and then goes into some type of frozen state.  The machines don't appear to be checking and the status.html page doesn't seem to update.  Eventually it starts working again.    Also, the last hour statistic may be a little high now.  I restarted the service after it seemed to be hung for several hours in order to get it back operational and likely is the backlog.

     

    Screen Shot 2017-01-26 at 3.55.11 PM.png

     

    The trace log seems to quickly fill with:

    Screen Shot 2017-01-26 at 3.56.27 PM.png

  4. Sorry to stir up an old thread, but has their been any resolution to this?  I am having similar issues with ERA 6.4 on a Windows 12R2 install with an external MS SQL server.  The resources on both system not taxed at all (usually around 10-20%).  However the log queue will show usually around 15k for most of the day.  At random times it will go back down to normal before shooting back up.  I worked with support a couple weeks back and basically was told that it was because I had third party application reporting enabled was likely the cause.  However, the issue came back.  Wanted to check here before I went round and round with support again.

  5. Just an update.  We migrated the DB off on to one of our enterprise SQL servers, but we are still seeing the same issue.  Neither the SQL server nor the ERA server is heavily tasked.  I worked with support the other day and they said it was likely due to my check in time for the ~3,600 clients was too frequent.  I had it set to 10 minutes and that was adjusted to 20 minutes. They also disabled the third-party software reporting saying that was likely the cause.  All was well into a few hours later when the problem returned.  Is anyone else seeing this?  Looking at the ERA Status file it is rejecting clients because the server is overloaded according to the status page.  We are running this on Windows 2012R2 for the ERA server, and the SQL server is 2014.  

  6. 7 hours ago, Marcos said:

    That could be it. See hxxp://help.eset.com/era_install/65/en-US/infrastructure_sizing.htm .  The recommended limit for SQL Express is 5,000 clients provided that the default connection interval 20 minutes is used and the number of records transferred from clients is within standards.

    Thanks for your help.  I don't think we had that when we first built the server, but either way looks like we are very undersized for what our planned usage will be.  Our Windows SQL DBA is on board with moving this DB onto one of enterprise SQL servers with a HA setup.  This leads me to my next question, is there any instructions/documentation available on migrating the DB onto another server and reconfiguring the console?

  7. I am running ERA 6.4 on Windows 2012R2 with a local MS SQL Express install. For the last couple of days, I have had a high number of pending logs (roughly 17k) showing on my dashboard.  This is causing clients not to be able to communicate to the server in a timely manner.  The resources seem fine on the server, 2 vCPUS running at about 50% utilization and previously 4GBs of RAM that was about 85% utilized. I thought that was a little high, so we increased to 6GB, but there wasn't really any noticeable difference.  Has anyone experienced similar issues?

  8. 1 hour ago, martbasi said:

    Hi,

    Hoping someone might be able to help with suggestions of how to approach troubleshooting this issue...

    On consecutive nights this week, SQL Express tempdb on my ERA Server has suddenly decided to fill the disk over a period of about 45min (~30GB or so). The server trace log showed nothing that seemed related and Eset support (via online chat) had basically no suggestions.

    Both times so far restarting the server OS (Windows 2012 R2) has cleared the space, but this has never been needed before.

     

    We received a similar alert from our systems team this week referencing this folder filling quickly. Any advice on how to clear out without impacting the server is appreciated.  Also running ERA 6.4 on Win 2012R2

  9. 1 hour ago, MartinK said:
    • You mentioned that one computer has not current timestamps in status.html - are there at least errors with current time? On the bottom of the status.html there is time this log has been updated: is it almost current? In case last update of status.html was not performed in last minute, it most probably means that this AGENT is not even running, and thus not connecting. Can you see process "ERAAgent" running on this machine?

    I am out of the office for the rest of the week, but I can probably gain access to some of the logs next week.  However, the "Last Error Log" showed a date/time well in the past.  For the post above, it was "
    Generated at 2016-Aug-31 10:25:26 (2016-Aug-31 06:25:26 local time)"

    Obviously, we are well into December now, but I am not sure if this is generated at the last time an entry was added to the log or the current time of the machine when I viewed the file.

  10. Just now, j-gray said:

    Oh yes. We've had a case open since August for the startup issue. I've tried the RC, as well and felt a small improvement but not enough to make it useable.

    The GUI is the cause of the issue.  We have found that forcing the GUI to not to try to launch will correct the issue.  I believe our OSX engineer modified one of the plist files that points to the location of the GUI will cause it to fail immediately.  The A/V component appears to function normally at that point, but we are hoping for an actual fix. 

  11. 2 minutes ago, j-gray said:

    FWIW, I have the exact same two warnings in yellow. The error I get in red is the same, except it's "failed with: connection closed by remote peer for session id xx"  'xx' being a specific session number.

    I have not opened a case on this yet, as I'm still spending a lot of time on the OS X startup delay issue.

    Have you opened a case for the OSX issue?  I am currently still working with support since roughly June on the OSX startup delay.  They provided an early release of 6.4 for OSX that doesn't appear to resolve the issue.

  12. 18 minutes ago, j-gray said:

    Thanks for the reply.

    In my case, I had three identical Macbooks next to me that had the latest agent installed. They've been powered off for several weeks. I powered them on today to do some testing and found that none were getting the latest policies. I searched 'All devices' including subgroups by both name and IP address and found none of the three.  Agents on two were still communicating with the ERA server. The third is not communicating at all. All three are configured the same (same model even).

    When I've encountered this in the past with Windows machines, uninstalling and reinstalling the agent always works. But this is not a solution. I'm not aware of a repair option for OS X. Re-deploying the agent yields a successful task, but changes/fixes nothing.

    The biggest issue is that when the agents quit functioning we have no way of knowing --they just appear to be another offline system and they no longer receive updated policies.

    I spoke with ESET Business Support on Monday regarding this issue.  We were able to get the machine working by reinstalling, and then it shows back up.  But as mentioned above, this is not a workable solution as there really isn't a method for knowing when they stop working.  I am able to determine this however through the AD sync task.  I am able to do the tedious process of looking through the objects and finding which ones are not "managed" .  I was a little disappointed in the rep not really wanting to look into the root cause.  However, I have been in communication with someone from your top business support on a few other issues that he has been very helpful with solving, so I was going to bring it up with him after the holidays.  However, I do have logs from one of the machines that I can provide.  The error showing in the last errors html file seems to be consistent with all of the machines that have the issue.  The ticket number from when I spoke with someone from support this week was: 1502830.  A sample from the last error log:

    CEssConnectorModule 2016-Aug-31 10:25:22 Requesting protection status log from product
    CEssConnectorModule 2016-Aug-31 10:25:22 Protection status content: 









     
     
    CEssConnectorModule 2016-Aug-31 10:25:22 Protection status log deserialized and published
    CSystemConnectorModule 2016-Aug-31 10:25:24 StatusLog_PERFORMANCE_USER_STATUS: "Rows":[{"symbols":[{"symbol_type":453,"symbol_data":{"val_int":[1]}},{"symbol_type":447,"symbol_data":{"val_uuid":[{"uuid":"442b1cd1-77ce-40f7-a9c7-94a0cbed839f"}]}},{"symbol_type":454,"symbol_data":{"val_time_date":[{"year":2016,"month":8,"day":31,"hour":10,"minute":25,"second":24}]}},{"symbol_type":456,"symbol_data":{"val_res_id":[508906757892866568]}}]}]
    AutomationModule 2016-Aug-31 10:25:24 Trigger: Tick ALLOWED [UUID=00000000-0000-0000-7006-000000000001, TYPE=REPLICATION].
    CDataMinersModule 2016-Aug-31 10:25:24 Machine is not idle because user is not idle
    SchedulerModule 2016-Aug-31 10:25:24 Received message: RegisterSleepEvent
    AutomationModule 2016-Aug-31 10:25:24 Task: Executing task [UUID=00000000-0000-0000-7005-000000000001, TYPE=Replication, CONFIG=scenarioType: REGULAR linkData { dataLimit: 1024 isDisabled: false connections { host: "[REMOVED]" port: [REMOVED] } }].
    SchedulerModule 2016-Aug-31 10:25:24 Received message: GetRemainingTimeByUserDataRequest
    CReplicationModule 2016-Aug-31 10:25:24 CReplicationManager: Processing client replication task message
    CReplicationModule 2016-Aug-31 10:25:24 CReplicationManager: Initiating replication connection to 'host: "[REMOVED]" port: [REMOVED]' (scenario: Regular, data limit: 1024KB)
    NetworkModule 2016-Aug-31 10:25:24 Received message: CreateConnectionRequest
    NetworkModule 2016-Aug-31 10:25:24 Attempting to connect to endpoint: [REMOVED]
    NetworkModule 2016-Aug-31 10:25:24 Forcibly closing sessionId:60, isClosing:0
    NetworkModule 2016-Aug-31 10:25:24 Removing session 60
    NetworkModule 2016-Aug-31 10:25:24 Closing connection , session id:60
    NetworkModule 2016-Aug-31 10:25:24 Sending message: ConnectionFailure
    CReplicationModule 2016-Aug-31 10:25:26 CReplicationManager: Replication (network) connection to 'host: "[REMOVED]" port: [REMOVED]' failed with: (0x2751), A socket operation was attempted to an unreachable host

     

    The date/times are all different on each of the ones that I have had to fix so there is no common theme there.

  13. First of all, we strongly recommend using an HTTP proxy for updates as it saves a lot of traffic/data unless you have dozens of thousands of computers. However, you can still create a mirror with v6 products, either by Endpoint, file/server v6 products or using a stand-alone command-line mirror tool that is downloadable from ESET's website. ERA v6 doesn't create a mirror any more.

    Would recommend you go the command-line mirror tool and serve them over an HTTP using your choice of web server product (Apache and IIS I have tested with).  The one built into the products is not designed for any large scale deployment.  

  14. Thanks for posting, Peter.

     

    In our case (refer to my link above), it's strictly a startup issue and affects all OS X clients (we have 10.11.5 and 10.11.6).

     

    The clients are joined to Active Directory via OS X native Directory Utility.

    We've disabled all components, except real-time protection, and set those options to least impact.

    Then; install the agent via ERA, then install the AV client via ERA.

    On subsequent network/domain logins, the systems hang for 2-5 minutes until the ESET icon finally appears in the menu bar. After that, everything appears to function properly.

     

    We have no unusual applications or configurations that should cause issues or conflict with AV.

    What version of ESET Endpoint are you running?

×
×
  • Create New...