CraigF

It appears this issue resolved following install of Detection Engine version 28382 (or one of the subsequent updates - there were 4 in a space of 10 hours), as we haven't seen the issue logged since. We have performed the uninstall/reinstall as suggested on one of our RDS farm servers, so we can see whether this makes any difference if we notice the errors return.

Many thanks for the prompt response cyberhash - I need to work on my search skills. Damned if I could find that post!

Hi, We have some devices that have outbound internet access blocked, but this prevents us from installing ESET updates. Hence, we'd like to whitelist the web server addresses for the ESET update servers. Is there a list of this web addresses - URLs and/or IP addresses?

We've noticed this phenomenon occurring on multiple Windows Server 2016 remote desktop services session hosts. For one of our clients it appears to be causing resource exhaustion issues causing the servers to become unresponsive. It appears a new instance of ekrn.exe is attempting to be created whenever a new user session is created - is this normal? Serves are running ESET Server Security vers 10.0.12014.0 Here's what I've determined: Windows Application log records Application error ID 1000 logged everytime a new user session is created: Faulting application path: C:\Program Files\ESET\ESET Security\ekrn.exe Faulting module path: C:\Program Files\ESET\ESET File Security\em039_64\2102\em039_64.dll Similarly, Windows System log records Service Control Manager ID 7031 error at the same time as the Application error is logged: The ESET Service service terminated unexpectedly. ESET event log indicates “File 'Ekrn_*.mdmp' was sent to ESET Virus Lab for analysis." each time. These events appear to have commenced immediately after the Detection engine was updated to vers 28271 (on 21 Nov). They started being logged a few hours prior to the Application error ID 1000 errors first being recorded. The ESET Audit log is now recording "Feature changed" events multiple times a day (I assume whenever a new user session is created and the ekrn.exe is run). Prior to 21 Nov, these events were only logged whenever the server was restarted.

I ended up running the esetuninstaller.exe tool (from Safe Mode reboot), and selected the option to just uninstall the Agent. I was then able to install the Agent. The ESET Support contact I dealt with had no knowledge of the ESET Management Agent uninstaller batch file that Marcos referred to.

After chasing up support they responded advising as follows: Can you create a bat file using the below command and run? cd C:\Users\Administrator1\Desktop msiexec /q /x agent_x64.msi PASSWORD=Test123 where the first row determines the folder where the MSI file is and the second row is silent uninstallation with parameter PASSWORD= (if the EM Agent is password protected - if not don't use the parameter) Tried this but it made no difference. @Marcos, is this the batch file you expected them to provide? I was expecting something similar to the Uninstaller tool, but targeted just at the ESET Agent.

I have logged a support request for the remover batch file as Marcos suggested (case #00636457). I'll provide an update once I hear back from the Customer Care.

As per original post, uninstalling the ESET Management Agent was one of the first steps we tried. It is no longer listed in Programs and Features, so if you're seeing evidence of it still being there it must not have uninstalled properly. Are you proposing that I run the ESET uninstaller (https://support.eset.com/en/kb2289-uninstall-eset-manually-using-the-eset-uninstaller-tool) and select removal of the agent? It's an Exchange email server so we'll need to organise a scheduled outage with the client, and I just want to check if this is the only course of action before proceeding.

Hi Marcos, requested log files are attached. Thanks! Logfile.zip emsx_logs.zip ra-agent-install-redacted.log

Hi Marcos, thanks for your prompt response. As you suggested, I created a standalone ESET Management Agent installer from our EST PROTECT server and ran this on each of the servers, and that resolved the issue.

We have client with an Exchange server running Windows Server 2016 and ESET Mail Security (v 10.0.10016.0). Server is fully patched. An automatic update of the ESET Management agent in early August resulted in it losing connection with our ESET PROTECT server (as described in this forum post https://forum.eset.com/topic/37686-eset-management-agent-not-connecting-following-automatic-upgrade-to-vers-10112880/) To resolve this issue we are attempting to install the ESET Management Agent locally/manually, but the install keeps failing with an MsiInstaller error status of 1603. Steps taken so far: 1. Created All-in-one (AiO) installer and attempted local install with that. 2. Uninstalled ESET Management Agent and reattempt install with AiO installer. 3. Restarted server and re-attempt install. 4. Create stand-alone Agent installer (PROTECTAgentInstaller.bat - saved to local folder on server) and attempt install with that. 5. Deleted these folders: C:\Program Files\ESET\EsetRemoteAdministrator; C:\ProgramData\ESET\EsetRemoteAdministrator; and cleared contents of C:\Users\admin.user\AppData\Local\Temp A review of the ra-agent-install.log (attached) suggests the problem lies with an attempt to access the missing DB file C:\ProgramData\ESET\RemoteAdministrator\Agent\EraAgentApplicationData\Data\data.db Please suggest how to proceed with this issue. ra-agent-install-redacted.log

We're an MSP running our own ESET PROTECT server to manage our clients' ESET endpoints. We have 3 server devices that had their ESET Management Agents automatically attempt an upgrade from vers 10.0.1126.0 to 10.1.1288.0 during August. From the update log (attached) it appears the update completed ok but required a restart to finalise the install. The agent ceased reporting to the server after the update. I have tried restarting one of the servers to complete the update however it still isn't connecting to the ESET PROTECT server. The servers are running Windows Server 2012 R2. We have a client server with similar symptoms - it's running Windows Server 2016. From C:\ProgramData\ESET\RemoteAdministrator\Agent\EraAgentApplicationData\Logs\status.html the issue appears to be with the Peer Certificate: Error: ParsePfxCertificate: PFXImportCertStore failed with An error occurred during encode or decode operation. Error code: 0x80092002 Check that correct peer certificate format (PFX/PKCS12) is used in the configuration Check that correct peer certificate password was set in the configuration Trace log has this infotmation reported each minute: 2023-09-05 01:29:26 Warning: AuthenticationModule [Thread 11f8]: EntityAuthenticationCommand execution failed with: [Failed to create credentials for communication], falling back to legacy implementation 2023-09-05 01:29:26 Error: AuthenticationModule [Thread 11f8]: EntityAuthenticationCommand execution failed with: Failed to create credentials for communication 2023-09-05 01:29:26 Error: CReplicationModule [Thread a38]: InitializeConnection: Replication connection problem: GetAuthenticationSessionToken: Received failure status response: AUTHENTICATION_FAILED (Error description: unable to authenticate entity) 2023-09-05 01:29:26 Warning: CReplicationModule [Thread a38]: InitializeConnection: Not possible to establish any connection (Attempts: 1) [RequestId: de96af0c-b777-4106-912a-0172678de3ed] 2023-09-05 01:29:26 Error: CReplicationModule [Thread a38]: InitializeFailOverScenario: Skipping fail-over scenario (stored replication link is the same as current) [RequestId: de96af0c-b777-4106-912a-0172678de3ed] 2023-09-05 01:29:26 Error: CReplicationModule [Thread a38]: CAgentReplicationManager: Replication finished unsuccessfully with message: Replication connection problem: GetAuthenticationSessionToken: Received failure status response: AUTHENTICATION_FAILED (Error description: unable to authenticate entity), Task: CStaticObjectMetadataTask, Scenario: Automatic replication (REGULAR), Connection: era.intense.com.au:2222, Connection established: false, Replication inconsistency detected: false, Server busy state detected: false, Realm change detected: false, Realm uuid: 24961e07-3654-49d5-a4d3-f90d4578cb38, Sent logs: 0, Cached static objects: 118, Cached static object groups: 11, Static objects to save: 0, Static objects to delete: 0, Modified static objects: 0 We encountered a similar issue with a client's Windows Server 2016 device and have attempted uninstalling and re-installing the ESET Management Agent, but that has proved problematic (has been escalated to apac.technical@eset.com) so thought it worth exploring problem further here, before attempting manual agent install. What steps do you recommend to resolve this issue? ra-upgrade-agent_2023-08-16T07-37-25.log

Hi Marcos, running a scan overnight after disabling scanning of Archives and Self-extracting archives still resulted in a 5GB HRL file, but that's a big improvement on 40+GB, so your hunch was correct. Thanks, Craig

Thanks for the prompt response, Marcos. To clarify, I should disable this setting: Detection engine, Malware scans, Threatsense parameters, Objects to scan, Archives but not Self-extracting archives. I will give your suggestion a go and report back once I've re-tested the scan.

Hi, We run monthly malware scans on our servers. From our Hyper-V replication log (*.hrl), we've observed that these scans result in 40+ GB of disk writes on the System volumes. These writes need to be replicated to the Hyper-V Replica server, which is problematic for remote Replica servers. From this post - https://forum.eset.com/topic/12397-what-data-eset-writes-to-ssd-and-how-to-minimize-it/ - it appears that ESET pages a lot of its scan processing to disk, which probably explains this phenomenon. Given that article is over 6 years old, I thought it worth checking whether ESET has any new settings that we can adjust to reduce the amount of disk write activity it generates when scanning. Thanks, Craig

We're trialing the auto-updates in house, prior to enabling it for clients. We had 4 of our 13 staff devices update back on 24 May, then nothing since. We got very excited when we first heard about the new auto-update feature (over 6 mths ago, I believe), thinking ESET was finally catching up to some of the other endpoint security solutions. But waiting over two months to deploy a new update is unprecedented for us, and not something I'm comfortable with. Factor in the seemingly "hit and miss" nature of it, and we're reverting to our established scheduled deployment process. I'll check this post in another 6 months to see if ESET have managed to sort the auto-update functionality out in that time. At this stage I'm calling ESET Auto-update an EPIC FAIL.

I agree with Ufoto, Trooper, LesRMed, Michael Erni etal; this delay in the auto-update process seems totally unnecessary and, quite frankly, appalling. We have always deployed updates in-house within the first fortnight of their release (to a pilot group of devices first, then all), and to our clients within the first month. Why is their deployment being delayed so long?

Based on the data we've collected regarding these alerts over the past two months, it seems that it's only devices that are connected to remote/home/wifi networks that are logging "The ESET LiveGrid servers cannot be reached" warnings. This leads me to believe that it is a network connectivity issue causing the alert. Can you advise what thresholds are applied to the alerts (e.g. how may connection failures over what period before the alert is generated), and whether these thresholds can be adjusted?

Marcos, we were scheduling our scans via a policy that added the task to the client's Tools, Scheduler. As you say, we can schedule via ESMC tasks instead, so will fall back to this option.

@Marcos, If I'm not mistaken, we can only schedule weekly scans via ESMC policies, not monthly. Can you verify this?

For the past week or two we've received Network Attack Alerts relating to Botnet.CnC.Generic detections across all our (Australian based) clients. According to VirusRadar (https://www.virusradar.com/en/home/world) this is currently the most common threat detection, yet I've been able to find no information about it. The detections are on inbound traffic from a small number of IP addresses. We're seeing them mostly on port 443 (as that is one of the few ports they have open), but we have seen it on port 2222 (ESET ERA) also. It's not clear whether ESET File Security is taking any action to block these threats. These are some of the source IP addresses we're seeing: 193.188.22.187 185.156.177.235 185.153.199.3 141.98.81.66 45.136.111.112 45.136.108.68 My understanding of CnC threat traffic is generally triggered from the infected machine so would be outbound rather than inbound, so I am somewhat confused by these notifications . Can anyone shed any light on how ESET detects a "Botnet.CnC.Generic" threat so I can determine whether this is something we need to respond to (e.g. is it just based on the source IP address?) Also, is anyone aware of CnC servers that would be spraying out traffic to web hosts?