Pabs

Hello, I started noticing that after installing ESET Server Security on my servers, that when copying files over RDP sometimes (depending on the file size) the operation will fail. I believe this may be because the security product is trying to scan the files in real-time as they are copied to the server, and the added latency might be breaking the copy/paste operation. Has anyone else encountered this? Any advice regarding how to exclude the clipboard operation would be super helpful! Thanks in advance!

Ok I will do that. There seems to be an issue in the era agent which is causing port exhaustion issues with my production VM's @Marcos I had the issue occur again today, was able to establish serial console access to one of my VM's only to see with a netstat command that the ERA agent had established thousands and thousands of connections. The list was endless. Edit: For now I've uninstalled and reinstalled the ESET Server Security and Remote Management Agent products to see if that helps cure the problem.

Anybody out there? 😓

I have verified that the virtual machine can reach the endpoint specified in the error over port 443 via telnet, would appreciate any insight to why we are getting this error!

additional info: I am investigating issues with my servers which are causing network outages. One line of thinking I am investigating is that somehow over a period of long uptime, the VM's are exhausting all sockets and then can't establish further connections. Either way, if this isn't related to that issue I still want to figure out what the heck this error is.

Hello, I have ESET Server Security installed on my Windows Server 2019 Datacenter VM's in Azure. For all of my VM's, the ERA Agent trace.log file shows repeated (a lot) of errors for failed health checks to a particular endpoint. I'll leave one such message below for reference. I'd like to figure out why this is occurring. Our servers only allow TLS 1.2 server protocols, and TLS 1.0,1.1, and 1.2 client protocols. 2021-10-06 13:14:26 Error: CReplicationModule [Thread 1828]: CAgentReplicationManager: HealthCheck failed with grpc error to (2tjwO_SOMETHINGLIKETHIS.a.ecaserver.eset.com) with error: Request: Era.Common.Services.HealthCheck.ServerHealthcheckRequest on connection: host: "2tjwO_SOMETHINGLIKETHIS.a.ecaserver.eset.com" port: 443 with proxy set as: Proxy: Connection: :3128, Credentials: Name: , Password: ******, Enabled:0, EnabledFallback:1, failed with error code: 14, error message: Endpoint read failed, and error details:

I did have issues with connecting to livegrid yesterday, when I configured GEO-IP filtering on my perimeter firewall appliance. Afterwards, I made a few exceptions for IP ranges related to the livegrid servers so that should be OK now and ESET endpoint security no longer displays the connection issues warning related to livegrid. To test the file download I had to make a quick exception since the IP resolves to Germany, but I was able to do that and it did show up as suspicious and was blocked. I think I might know what caused the TCP port scanning... I was messing around with spiceworks inventory system and I think it tried to scan things on the network. I'll uninstall that and keep a close eye to see if anything else happens that may not be related, and thank you for all your help!

Hi Marcos, I've attached the logs from today, please let me know if I missed anything or if you need anything additional. Also, thank you kindly for the help. ees_logs.zip

Hello, I am seeing a large number of TCP Port Scanning Detections in the ESET Protect Cloud portal, all of which *alarmingly* are coming from my machine's private IP address. My question is, how can I drill down / troubleshoot on my machine to figure out what the root cause of this is? Thank you in advance for any assistance.

Hi Marcos, Thank you for your reply. This info helps, as I was worried this would be the case every time. Unfortunately, I cannot restart my production servers whenever I would like, so the update making real time protection non functional is somewhat of a hassle because I either need to perform an emergency reboot, or schedule a restart overnight. Until the restart happens the system will remain unprotected and that is obviously not good. However, it would be nice to see a warning in the protect cloud console when performing a task for update without automatic reboot as to whether or not this will be the case. If something had told me that the protection would be disabled until reboot I would have been able to make a more informed decision in this case. I may just be shouting in the wind here but anywho, thanks again for the information.

Hello, I run ESET File Security on my production windows servers. Can someone please explain to me why updating the software makes real-time protection nonfunctional? This seems like a huge product flaw. What I would like to do is update the application, and schedule a time for the server to restart. Real-time protection should remain functional until the time of the restart. Why even allow updates to be applied without a reboot if this is going to be the result?