zhopkins

For what its worth, we tested the updated 9.0.12013 client on one of our AWS VMs, and it came back up successfully after a reboot.

We seem to have run into this issue as well. We've been testing 9.0.12012.0 for our on premise servers for a couple of weeks with no reported issues, but we lost 3 AWS VMs (Server 2019 Core) to this issue yesterday. Upon initial install, the servers were okay, but as soon as they were restarted, they never came back up. We were able to ping the servers for a little while, but RDP, Remote Management, and even the ESET Management Agent never came up, so we had no way to access them.

Yes, Peter. In my initial testing, trying to read the main log files (/var/log/messages and /var/log/secure) using the "less" command, they displayed the "Waiting for data... (interrupt to abort)". I saw this behavior when I opened the log files 5 times in a row. As soon as the efs daemon was stopped, I was able to run the same command, with no such message. --Zachary

Peter, I was able to spin up a fresh VM and do some additional testing. ESET Server Security v8.1.565.0 immediately starts logging eset_rtp errors in the main "messages" log file (even on a blank VM with just our base OS install). The slightly newer version, v8.1.685.0, does not seem to cause these error messages. With the latest version (8.1.685.0), I have noticed a strange behavior with the 'less' command, and I am trying to do some additional investigating to see if that issue is still related to the issue in this thread. The less command (literally "less /var/log/messages") triggers a "Waiting for data... (interrupt to abort)" message on nearly every open of the log file. This behavior is abnormal in our environment, so I want to be sure that the newer version of the antivirus is still not causing issues or delays when opening files.

Peter, As it happens, we do already have Performance Exclusions in place for our Oracle database and Icinga. Additionally, when I first saw the issue on those servers, the first thing I did was to modify the ESET policy to disable scanning on file open (leaving only on file creation), but that did not seem to help. I might not be able to get to it this week, but I will spin up a server with the newer version of ESET so I can do some more direct testing for you all to try and figure this out. Thank you, --Zachary

Peter, Some examples for you - RHEL6 / Oracle / EXT4 local disks / CIFS remote shares RHEL7 / Oracle / EXT4 local disks / No remote shares RHEL7 / Icinga2 / EXT4 local disks / No remote shares RHEL8 / DNSMasq / XFS local disks / No remote shares I'm fairly certain that we are not using EDTD, since that is a separately licensed product? It does not appear in the "Products & Licenses" section for the machines in the ESET PROTECT console. Overall, I believe most of the servers (some physical, most virtual) managed to get through with only minor slowdowns, however, the server that runs our Icinga monitoring became extremely unresponsive, to the point where I was unable to login via SSH or the console (even with root credentials). I had to push a task through the ESET Management Agent to stop the EFS daemon before I could log in.

Not to hijack the thread, but we also ran into this same issue last week on Red Hat 6, 7, and 8 on both available versions of ESET Server Security in the 8.1 branch (8.1.565.0 & 8.1.685.0). The older ESET File Security 8.0.375.0 seems to be unaffected. At the time, we had no choice but to immediately stop the EFS daemon and subsequently uninstall it to restore our services. So, I don't have a lot of troubleshooting information from during the event. However, since we would like to eventually update the software, I would be happy to provide additional information or participate in testing to help figure things out.

Marcos, the clients in question are all servers. They are online 24/7 and check-in every few minutes to ESMC.

Martin, We restarted the ESMC server late last night, in hopes it would help the task to run at its scheduled time this morning. That did not help. However, restarting the client machines that were supposed to run the task, did help. Once restarted, the client machines immediately began to run the task. I also verified that the task UUID shows up in the trace log, and sure enough, it was right there on every single one (showing "generate a tick for a missed event", timer registration for the next occurrence, and the actual task execution). Your note about this being more likely to happen as time progresses also seems evident in our environment - roughly a third of the machines missed the task on the first run, followed by half on the next run, and closer to 2/3 on the subsequent runs. Thanks for posting, we'll be on the lookout for the next release!

Even when changed from a CRON expression to just a weekly event, the clients are still not running this weekly task. I can manually select any client, and add the task with an "As soon as possible" trigger, and the client will begin execution immediately, so the overall task is fine, its just that the reoccurring task simply doesn't run on a random portion of the assigned clients. If anyone has any suggestions at all, it would be much appreciated!

MichalJ's suggestion worked for us. We marked all of the related firewall alerts as resolved, and then modified our server policy to have the Log, Block, and Notify options set to "No", and it has been quiet ever since. B-G, just to confirm - if you open the File Security client on one of your machines and check its setup, I assume that you can see your desired IDS configuration there, with all of the options set to No? (Just making sure that it received the corrected policy)

Yes, we're seeing this behavior too. After setting the first batch of alerts in ESMC, I found this post. I then added the policy exception (any alert, with a specific remote address, all other options at default), and marked the old threats as resolved. 24 hours and another Nessus scan later, and the alerts are back.

We've setup a client task to install OS updates on a weekly basis to a select group of servers, but for several clients this task still shows as planned, never executed. We've gone through two weeks now, and the task still hasn't executed, with seemingly no explanation as to why. The client task runs the "Operating System Update" task. "Automatically accept EULA" is checked, "Install optional updates" is un-checked, and "Allow reboot" is checked. The trigger is applied to 25 individual clients, with a CRON schedule, "0 0 3 ? * FRI *" (Every Friday at 3am), no random delay, "Invoke ASAP If Event Missed" and "Use Local Time" are both checked. The trigger shows "Planned - Yes" for all 25 clients. The trigger shows "Last Status - Finished", along with a Last Progress Time and "Progress - Task finished successfully" for 17 of the clients. The remaining 8 clients have these 3 fields blank. All of the clients are checking in with the server at 5-minute intervals. The status.html files on the clients are all green. All of the clients are Windows 2008R2/2012R2, with Management Agent version 7.0.553.0. The server version is 7.0.553.0. All of the clients had at least 5 updates available and ready for install when the task was created. The agent trace logs appear unremarkable. Our timezone is US/Eastern, UTC-0400. The trace log from a client not executing the task is devoid of useful information (I checked at least 3 of them, and they only show the one line from today). I also checked a client that ran the task successfully last week, but had no further updates to install this week. This client's trace log for today looked identical to the client that isn't running the task. 2018-09-28 12:03:51 Warning: CEssConnectorModule [Thread 178c]: Set policy request to product was successfull The trace log from a client that did execute the task this morning, and successfully installed updates, looks to be chock full of details (file attached). If anyone has any thoughts or suggestions as to why some clients aren't running the tasks as requested, they would be much appreciated. Thank you! eset-tracelog_clientwithupdates.txt

Has anyone else seen this warning message from Google Chrome? The message could be closed by typing in a different web address or re-launching the browser. The machine in question is running Windows 10 Education (1703), Eset Endpoint Antivirus 6.6.2072.4, and Chrome 67.0.3396.87. We're still testing Windows 10 build 1803, which won't go out for another month or so. We're also testing Eset 6.6.2078.5, which should be pushed out within 2 weeks, but I'd like to make sure that we're not about to get bombarded with a headache. Thanks!

While the instructions provided in KB6512 work to manually enable the System Extension for Eset, are there any plans to automate this process for new installs or upgrades from ERA? We have 200+ computers running MacOS and the end users do not have administrative rights by default. We'd like to be able to push out the latest version of Eset Endpoint Antivirus (6.5.432.1) from ERA as folks transition from earlier versions of MacOS and Eset, but if they're going to be prompted to do something that they don't have rights to do, then that puts us in a bit of a pickle, adding additional work and manually touching the machines. If anyone from Eset has any knowledge on this topic, or if any community members have found a work around in the mean time, I'd love to hear. Thank you!

For reference, the agent status page on macOS is located at /Library/Application Support/com.eset.remoteadministrator.agent/Logs/status.html.

For reference, we've seen similar results in our environment. Most Mac clients would show up in ERA with a ".local", while a few would show up with the FQDN. We also had the added issue that some of our Macs were missing local configuration options, and while they would allow for Active Directory logins, their hostname (via command line) would not always match what was configured via the GUI, nor would they always show the FQDN. The quickest workaround that I found to eliminate duplicate computer accounts in ERA for our Mac clients was to alter the task on the ERA server that renamed synchronized computers. Instead of having it rename by FQDN, I switched it to just rename by Computer Name. Under this configuration, we no longer have duplicate accounts for our Mac clients. All of our Windows clients still show up in ERA by their FQDN, and the majority of our Mac clients now do too. Only 27 of our Mac clients (approximately 16% of our reporting Mac population) show up with just a short name. It may not be a 100% perfect solution, but it has eliminated our duplicate computer issues and given us a more accurate machine count.

If you're looking to upgrade the management agent on your clients, or the server components on your server, there is a built-in task to do this. The "Remote Administrator Components Upgrade" client task will upgrade these items for you. When applied to a regular client (a workstation or file server), the ERA agent will be upgraded to match your ERA server. When applied directly to your ERA server, it will download and install the latest server components from Eset. It usually takes a few minutes for the clients to upgrade, depending on your connection interval, but the last server upgrade I did took a bit longer, at around 30 minutes.

It took a little bit of fiddling, but I've been able to get Regex working in several of our templates. I've built most of my RegEx strings through sites like regexr.com or regex101.com, with some slight modifications to signify the beginning and the end of the strings. 1) Looking for clients that have some point-release of a version 5.x client installed (i.e. any 5.x version): "Installed software.Application version" → RegEx → "^5.\d.\d{4}.\d$" 2) Looking for clients that do not have "Server" in the operating system name: "OS edition.OS name" → RegEx → "^(?!.*Server).*$"

We have several dymanic templates for machines without Eset installed. This allows for our technicians to install the ERA agent, and then the actual antivirus installation is handled automatically by the server. As an example, here is a template for computers that do not have the Eset Endpoint Antivirus Client installed. This can easily be adapted for Eset's other products. I have not specifically seen anything that would allow for the detection of failed installations, following an install attempt from this dynamic group, though maybe others have found ways to do this.

Has anyone heard of plans to release an updated version of Eset File Security for Linux? Running on CentOS 7, the ERA v6 agent seems to run fine, but none of the settings from ERA are applied to the antivirus program, nor am I able to get the real-time file scanning working. Thank you!

Unchecked, you say... It was checked in our policy. Looking back, I see that there is not a matching check box for the Windows antivirus clients. Since it was present for the Mac clients, I figured it had to be checked in order for that section of the policy to be active. Whoops! Thanks for your help!

Has anyone else had issues with the Endpoint Antivirus on Mac blocking all web traffic when one or more URLs have been added to the "Blocked URL" list? We've added 3 sites to our block list via ERA, and while the Windows computers seem fine (only blocking the 3 listed sites), the Mac clients are blocking everything until the policy is removed. I've already been talking with Eset Support about this, but I am curious if any other users have experienced similar issues. We've seen this issue present in version 6.0.24.0 through the current 6.1.16.0, on OS X 10.9 through 10.11. Thanks!

After using ERA v6 for the past few months, I figured that it would be a good idea to install a better SSL certificate. By default, the Webconsole was using a certificate with almost no information filled out (no Common Name, Organzation, et al), making it difficult to truly trust. Getting a proper certificate installed (i.e. one that was signed by either a trusted internal CA or an external commercial CA), turned out to be a bit tricker than I expected. I am documenting the process that I went through, so that it might be of use to others. Currently, ERA v6 (Server 6.1.444.0 / Webconsole 6.1.334.0) does not offer any way to import or view the certificate that is used for the Webconsole. To generate a CSR and get the signed certificate installed, you will need the latest Java JDK and a copy of OpenSSL. For convenience, I installed the JDK on the same server as the ERA, since it will be used to import the certificate directly to the Tomcat keystore. First, you need to gather three pieces of information from your ERA's Tomcat configuration. These are generated behind-the-scenes during the installation process. Our server is running on Windows, so for us the file is located at "C:\Program Files\Apache Software Foundation\Tomcat 7.0\conf\server.xml". Near the end of this file is a line that starts with "<Connector server="OtherWebServer" port="443" protocol="HTTP/1.1" SSLEnabled="true"...". Make a note of the values for "keystoreFile", "keystorePass", and "keyAlias". - The default keystoreFile value should be "C:\Program Files\Apache Software Foundation\Tomcat 7.0\.keystore" - The default keyAlias should be "tomcat" - The keystorePass will be randomly generated Use OpenSSL to generate a certificate signing request (CSR), then use your internal or commercial CA to sign the certificate and receive a PEM formatted certificate. openssl req -out ERA.csr -new -newkey rsa:2048 -nodes -keyout ERA.key Now, you need to combine the private key (ERA.key) with your signed certificate (ERA.cer). Run the following command with OpenSSL to combine them into a PKCS 12 file. When prompted for an Export Password, use the same value from the keystorePass field. openssl pkcs12 -export -in ERA.cer -inkey ERA.key -out ERA.p12 -name tomcat Before the new certificate can be imported, you will need to backup the old keystore file (copy it somewhere safe) and then delete the old certificate with the following command on the ERA server. I am running the keytool commands from the JDK bin directory (e.g. C:\Program Files\Java\jdk1.8.0_45\bin\). Replace "_YOUR_keystorePass_" with your actual keystorePass value. keytool -delete -alias tomcat -keystore "C:\Program Files\Apache Software Foundation\Tomcat 7.0\.keystore" -storepass _YOUR_keystorePass_ You can verify that the keystore is empty by running the following command. keytool -list -keystore "C:\Program Files\Apache Software Foundation\Tomcat 7.0\.keystore" -storepass _YOUR_keystorePass_ With the keystore empty, you can now import your new certificate. keytool -importkeystore -deststorepass _YOUR_keystorePass_ -destkeystore "C:\Program Files\Apache Software Foundation\Tomcat 7.0\.keystore" -srckeystore "_Path_to_your_ERA.p12" -srcstorepass _YOUR_keystorePass_ -srcstoretype PKCS12 -alias tomcat FInally, restart your Tomcat service and you should be able to load up your Webconsole and see the new certificate in use! I'm sure that there may be a shorter set of commands to accomplish this, or that such functionality with be integrated into ERA in the future, but until then, I hope this helps!