Peter Randziak

I checked it at my SLES 12.4 and ESET File Security works for me. I find the cause of the issue. It is that Apparmor is enabled by default at SLES 12.4. It is needed to disable Apparmor completely and reboot the system and than install ESET File Security and it works as expected.

Just for testing purposes can you check if it is working with newest version? It could be interesting to know, if issue is present too with new version. There can be some changes in SLES 12.4

May I ask why are you installing 4.5.11 when 4.5.13 is available?
https://www.eset.com/int/business/file-security-linux/download/
- I would suggest to uninstall previous version and make clean install of version 4.5.13 and check if issue persist.
reboot system after uninstallation

Hi,
I have switched to Outlook 2019 a few days ago and since then, I have not experienced duplicate messages after re-enabling "Integrate into Microsoft Outlook" and all the scan options except "Sent email".
Keeping fingers crossed...

Yes, this mean that clients starting with latest version of 7.0 will be automatically updated to 7.1 once the micro PCU is enabled on our servers and in the Endpoint settings.  Previously the functionality was ready, but was not enabled due to it´s behavior, where the "reported version" was not changed in ESMC, even when the client was updated over micro PCU. This is now changed and we will be enabling it soon. 

Just noticed my join date of June 2, 2013.
That's also the day I installed NOD32 on three computers.
Now I have ESET products on five computers.
No complaints at all.

Being back is wonderful!
Now let's see if I can go more than two weeks without having a relapse.

What about this  how you like it?

I'd start off by:
- gathering and providing ELC logs
- generating and providing a Procmon log from time when the issue occurs
- generating and providing a complete memory dump when the system freezes (https://support.eset.com/kb380)
- raising a support ticket for customer care so that the case is properly tracked.

Hello, 

for this, you should use Client task -> Mobile -> Anti-Theft Actions -> Platform: iOS DEP -> Command: Find (Turn on Lost Mode). 

The device can be unlocked afterward only from ESMC Web Console with "Turn off Lost Mode " task.  

@Roger Nock You are indeed right. If you disable firewall "permanently" it would switch the feature to "OFF state" which does not generate any error on the management console side. If you pause it, protection state is switched to red, and warning is displayed. This behavior is non consistent with other functionalities, and If I do recall correctly we are tracking already a change request to make it more consistent and also report the state of the features more clearly inside the management console. Thank you for pointing this out. 
Internal reference for ESET staff: IDEA-1256, P_ESMC-16751

Here is detailed explanation how to properly install ESET NOD32 Antivirus for Linux desktop at Ubuntu 18.04
To install ESET NOD32 Antivirus for Linux Desktop on Ubuntu 18.04
Open Terminal Set root password using command (sudo passwd root) Install glibc library using command (apt-get install libc6:i386) Install libappindicator1 to show icon in upper tray using command (apt-get install libappindicator1) Download the install package and set the execute privileges Install package, reboot, icon will be shown at upper right corner  

@Palps,
Thank you for sharing this information.  In my case, I already had HIPS disabled in the client policy and I had the application status disabled as well.  I'm not sure why using the Security Management Center Components Upgrade task was still hit and miss.  As @tmuster2k pointed out, I got all my clients updated by downloading the .msi files for EEA and ERA and then using my patch management software to deploy.  At least it is working for you though and you are able to get your clients updated.  Thanks again for the information!

Hello,
@T3chGuy007 I had the same issue for each update of the Agent version sind the beginning of v6. Every time I have contacted the support but they couldn't help.
I have figured out, that the HIPS Module is blocking the deletion/stop of the process ERAAgent.exe and the service EraAgentSVC. So as a result the agent cannot be updated.
Currently I am doing the upgrade to EMA 7.0.577.0 and EEA 7.0.2100.4. For this I have changed the default policy for all clients, so that HIPS is disabled but not shown as Critical on the device itself, so that the users are not getting confused. Then I am waiting until they have rebootet and trying to do the Agent update from time to time. As soon as HIPS is disabled and a reboot has been done, the Security Management Center Components Upgrade task is working like a charm because the process and the service is not secured by the HIPS anymore.
I have figured this out by myself as the support was never able to help me. Currently we are considering to switch to another AV solution.

(Disabled HIPS)
 

(Change application statuses)
 

(Disable to show the issues on the client)
 

@tmuster2k
I downloaded the agent and antivirus .msi files from ESET's website and I first tried to deploy the agent through my patch management software and it failed.  I looked at the log file and I had several of these messages with a different .exe listed.  So I tried deploying the .msi for the antivirus and it worked.  I then tried the agent .msi again and it worked!  Thank you for the suggestion!  From now on, I'll use an AIO installer for new installs and then just download the .msi for upgrades.  Thank you again!!  
Info 1603. The file C:\Program Files\ESET\RemoteAdministrator\Agent\ERAAgent.exe is being held in use by the following process: Name: ERAAgent, Id: 3176, Window Title: '(not determined yet)'. Close that application and retry.

Hello @ofer1954 & @Roger Nock
We have experienced unexpected difficulties during upgrade of ESET Cloud Administrator backend to the newest version. As a result some instances were temporarily started with "empty DB" meaning that previous configurations and state was temporarily lost. We have re-setup the instances from the DB backup, meaning all should be back to normal and policies were restored to the original state.
We are sorry for the inconvenience and issues caused. We are working with the teams involved to further optimize our internal processes to prevent such issues from happening in the future. 
@ofer1954 You have said that it was not a first time that problems occurred. Can you please tell us more details about the specific issues you have experienced? 
Thank you both for understanding.
Michal 

Hello,
I just wanted to confirm Zoltans info.
EEA 7.0.2100.4 is working without any issues.
The versions before had the update issue.
Regards

Dear Linux community,
 
We’ve been working on the new generation of our solution for Linux servers for quite a while.
The hard work of the development and QA team was materialized into the first BETA version, which we would like to share with you.
 
If you are interested in getting a copy and chance to get hands on experience with it, just leave a comment here or send me (@Peter Randziak) and @TomasP a private message.
We are looking forward to your participation.

Hi mogobjah
It looks like some issue with corrupted installation or missing modules.
At first check prerequisites which is GlibC:
- It is needed to have instaled glibc to run 32bit applications at 64bit os
yum install glibc.i686
- check if all modules are present, if some of them are missing it could be the issue.


Anyway if they are present some of them can be corrupted somehow and therefore:
- Login as root
- Stop esets service
- create backup folder
- Move em00*_32.dat files from /var/opt/eset/esets/lib to backup folder
- Run update all modules will be re-created again /opt/eset/esets/sbin/esets_update --verbose
- Check content of /var/opt/eset/esets/lib if all modules are present
Try to start service and check if issue is fixed or not.
 

A nice addition to the Forum...hopefully folks will take the time to read it.

 

Hello @Miko Levy,
yes, sure the process is well described in our KB at https://support.eset.com/kb141/?locale=en_US&viewlocale=en_US 
Thank you in advance for your future submissions ;-),
P.R.

thank you very much! :)

Hello Howard,
We are indeed in the process of switching from 32-bit modules to 64-bit modules.
The 64-bit module are being tested and will be released via an update soon, so currently the app runs 32-bit modules, but there is full compatibility and full protection even on 64-bit systems and thus nothing to worry about.
Now why you saw "64-bit" in the about screen earlier - this was simply a bug, which instead of the modules showed the bit-ness of the system. We fixed the bug in the latest release and now it correctly shows the bit-ness of the modules.
Regards,
Tomas

For future reference -> this is actually bug in ESMC itself and should be resolved for upcoming releases. In case there would be no issue, weak ciphers would be disabled in so called "Advanced security" mode which is available in ESMC's configuration. Those weak ciphers are available only for older ERA Agents connecting from even older operating systems (Windows XP, ...) where no secure algorithms were available in system.

Hello,
I'm ceterisparibus and I have been using Eset products (currently Cyber Security Pro for Macs) for about 4 years. I run them on Mac OS (both Mojave and High Sierra on two different computers). I look forward to reading the forums.