Jump to content

brandobot

Members
  • Posts

    64
  • Joined

  • Last visited

Posts posted by brandobot

  1. We're running ESET Endpoint Security for AV/Firewall,etc.. version 6.5.600.1 and am noticing huge slow downs after installing CarbonBlack Response 6.1.3. the esets_daemon process spikes up to over 100% cpu usage after CarbonBlack is installed.  I've tested on both 10.13.4 and 10.12.6. We've had both CarbonBlack and ESET for some time back in 2017 without any issues, but ended up removing CarbonBlack for the past couple months due to the kernel panic issues.

    Simple tasks such as launching terminal takes 20 seconds or attaching an image to an Outlook e-mail takes a minute and sometimes presents the spinning beach ball.

     

    Removing CarbonBlack makes the slowness go away and leaving CarbonBlack and removing ESET also makes the slowness go away. Seems like there's some incompatibility here. Is anyone else running these two products and are experiencing the same issue?

  2. 2 hours ago, j-gray said:

    Unfortunately, we're left with uninstalling/reinstalling the agent using third-party tools.

    Specifically, I run a report of unmanaged systems (we use AD sync to populate all systems) then export to csv. Then import the csv into ARD and run an uninstall script on all systems. This only works for those systems online, of course. Once the script completes, I then run a deploy agent task on all unmanaged systems, hoping to catch the ones I just uninstalled. I have to do this almost daily.

    Not an ideal solution at all, but best I can do.

    If ESET would ever come up with a simple ping sweep tool to replace the deficient RD Sensor, this might not be so painful.

    Thanks. I wonder if there's a command I can run on  an endpoint to see if a machine can actively connect to ESET. If so, I can probably script something to do a check once a week, and if it's not connecting, I can have it reinstall.

  3. On 2/27/2018 at 7:40 AM, j-gray said:

    I have a case open for this issue with OS X (since May of last year!).

    I'm told, at least in our case, it's due to database corruption when systems do not shut down cleanly (e.g. power outage, etc.). They're working on a new agent build but have no timeline on a release data AFAIK.

    Same exact response I got. They provided me with a "beta" version that was created to address this issue, but I am still experiencing it with the beta version.

    How are you handling this now? Our Infosec is not okay with having machines "unmanaged." We've had to uninstall and reinstall  the ESET agent periodically on all machines as we have no accurate way of telling which machines are connected.

  4. On 2/15/2018 at 1:40 PM, j-gray said:

    Best bet (in my experience) is to run the agent package using msiexec and the quiet uninstall (/quiet /uninstall) option. A reboot is not required before re-installing the agent.

    Unfortunately, the install task from ERA copies the agent msi into a temp folder, so it may no longer be available. If that's the case, one must copy the msi file and then run it:

     

    We've found that the agent (both Windows and OS X) frequently stops working properly --still running, but no longer reporting and/or stopping/restarting frequently). In these cases ERA cannot uninstall it and deploying the agent again does not fix the issue. The only option is to use third-party tools to uninstall the agent, then reinstall it.

    We're also experiencing the agent is falling off on Macs. Haven't checked Windows yet. We're seeing approximately 20 Macs per month losing connection and require an uninstall/reinstall. Huge pain!  I posted for help here as well.

     

  5. @michalJ @marcos

    I've opened a forum post here. It is case #103515 Machines missing from ESET Remote Administrator console"   --

    Web control case is # 33848. This case stemmed back from early 2017, we worked on this for months with no resolution. Support came on-site and was able to replicate both onsite and on ESET provided machines; however, no resolution was ever found.

    The machines missing and losing connection from the remote administrator is extremely urgent in our environment as we have no way of actively telling which machines are missing from the console. We've had to uninstall/reinstall the agent on all machines numerous times to ensure we're able to manage 100% of our Macs.

    The automatic task that wasn't working was for removing stale machine entries. Support told me there was an issue with checking the "remove license" option. After unchecking the option, removing stale machines began working.

  6. Still an issue. I was provided with a Beta version of the remote administrator app, version 6.5.376.30 that supposedly provided a fix for this issue. (was told it was a database issue) .

     

    Attaching screenshots of the endpoint being online and able to reach the ESET remote administrator server, but has not shown checked in in over 10 days.

     

     

     

     

    Screen Shot 2018-02-22 at 10.23.14 AM.png

     

  7. It's issues like this that make me feel like ESET was not Enterprise Ready -- especially on the Mac side.

    We've seen issues from machines mysteriously losing connection or being completely removed from the ERA, to auto-run tasks that just do not work, to tremendous slowdown issues with the Web Control feature on Macs. It's extremely tiring having to contact support, send countless number of logs and to hear no resolution for months.

  8. The part I redacted was the IP, not the hostname. But yes, it can reach both short name, fqdn, and IP.

    Just for clarification, this is what it looks like. (I changed the IP). Is was pointing to an IP,  not a hostname.)

    Scope Time Text
    Last replication 2017-Dec-21 18:45:46 Error: CReplicationManager: Replication (network) connection to 'host: "10.12.190.32" port: 2222' failed with: Network is unreachable
  9. Yeah, I had originally uploaded the status, which you removed. I'm re-attaching it now.

    Note that we've connected to this machine, and was able to communicate to our IP on port 2222 successfully. On machines that had the same error, we've uninstalled the agent and re-installed and it'll reconnect successfully. Obviously, this is not a feasible task for us to do every time a machine disconnects.

     

    Status log

    Scope Time Text
    Last replication 2017-Dec-21 18:45:46 Error: CReplicationManager: Replication (network) connection to 'host: "REDACTED" port: 2222' failed with: Network is unreachable
    Peer certificate 2017-Dec-21 18:45:11 OK
    • Agent peer certificate with subject 'CN=Agent at *' issued by 'CN=Server Certification Authority' with serial number '011ab7527957a342d5867130df08e51ebd01' is and will be valid in 30 days

    Performance

    Indicator Value
    Up time 00:00:44
    Kernel time 0 sec., 0.0 % of up time
    User time 2 sec., 4.5 % of up time
    Memory private usage 44 MB
    Memory working set 722 MB
    Memory peak working set 722 MB
    Available physical memory 1166 MB
    Total I/O reads 0 KB
    Total I/O writes 0 KB
    Total I/O others 0 KB

    Generated at 2017-Dec-21 18:45:46 (2017-Dec-21 10:45:46 local time)
  10. We're currently experiencing client endpoints losing connection to our ERA. Below is the last error log. I removed the host IP for security reasons.

    On the endpoint itself, I can do a "nc -z <IP> 2222 and it'll connect successfully. We've experienced this on 38 machines since June 2016. Our workaround has been to uninstall the ERA Agent and Reinstall the Agent. Has anyone experienced this issue before?

    macOS 10.12.6

    trace.log

×
×
  • Create New...