MichalJ

Just installed this certificate (with the aid of internet explorer) in the collection 'trusted root certificates' and the annoying error when launching IE or Chrome is gone. This will do for me for now. Thanks again.

Hello serlockwright,
thank you very much for your question.
Please, could you provide more details about your environment? (Version of ESET Mail Security for Microsoft Exchange Server (my recommendation is newest one); MS Exchange version in hybrid-mode).
I suggest firstly look at the following:
Make sure, that you are using hybrid Environment (it is prerequisite for this feature: https://help.eset.com/emsx/7.1/en-US/idh_xmon_ondemand_hybrid_dlg.html)  Look if you have configured Office 365 Account: https://help.eset.com/emsx/7.1/en-US/idh_config_mailserver_ondemand.html#office365 Thank you very much for using ESET product
We will be happy if we can help you to find a solution to your problem or if we can improve our product.

After cleaning old ESET file security 4 Linux & agent files I installed using the commands given below.
Worked like a charm on RHEL8!
On RHEL7 I had to killed the first startd (parent init) to get the other processes running.
Looks as a major improvement compared to the old 4 version. Did not test thoroughly yet.
Needed "systemctl enable eraagent && systemctl start eraagent" to survive a reboot.
 
# wget https://download.eset.com/com/eset/apps/business/efs/linux/latest/efs.x86_64.bin # wget https://download.eset.com/com/eset/apps/business/era/agent/v7/latest/agent-linux-x86_64.sh # sh ./efs.x86_64.bin # {yum|dnf} install efs-7.0.1152.0.x86_64.rpm # /opt/eset/efs/sbin/setgui -gre # /opt/eset/efs/sbin/startd # sh agent-linux-x86_64.sh --skip-license --cert-auto-confirm \ --hostname=raserver --port=2222 \ --webconsole-hostname=raserver --webconsole-port=2223 \ --webconsole-user="user" --webconsole-password="password" : Initialized log file: /var/log/eset/RemoteAdministrator/EraAgentInstaller.log : ESET Management Agent Installer (version: 7.1.367.0), ... Creating directories... : Service started. Product installed. # ps -ef | grep efs root 6319 1 0 12:53 ? 00:00:00 /opt/eset/efs/sbin/startd eset-ef+ 6323 6319 0 12:53 ? 00:00:00 /opt/eset/efs/lib/logd root 6324 6319 0 12:53 ? 00:00:00 /opt/eset/efs/lib/sysinfod eset-ef+ 6325 6319 3 12:53 ? 00:00:20 /opt/eset/efs/lib/updated eset-ef+ 6326 6319 0 12:53 ? 00:00:00 /opt/eset/efs/lib/licensed eset-ef+ 6327 6319 0 12:53 ? 00:00:01 /opt/eset/efs/lib/confd root 6332 6319 0 12:53 ? 00:00:00 /opt/eset/efs/lib/oaeventd eset-ef+ 6337 6319 22 12:53 ? 00:02:34 /opt/eset/efs/lib/scand eset-ef+ 6404 6319 0 12:54 ? 00:00:00 /opt/eset/efs/lib/webd/backend/webd eset-ef+ 6418 6319 0 12:54 ? 00:00:00 /opt/eset/efs/lib/authd root 6769 6319 0 12:59 ? 00:00:00 /opt/eset/efs/lib/execd

It's clear now. You clicked the Settings tab to view a policy instead of selecting Edit from the menu:

 

 

Is there any known method you are already using to fetch FQDN on those machines? For example some command line tool, shell command, etc.? Does output of any of following command:
hostname hostname -f scutil --get ComputerName scutil --get HostName scutil --get LocalHostName sysctl -a mention value that could be possibly used as FQDN?
We have already seen machines that were configured in a way that they were not aware of their's FQDN, it was available only on DNS servers, but that is problem for ESMC Agent which requires data to be available locally.

Value of kern.hostname should be actually used by AGENT so setting it should resolve problem. There is definitely no need to reinstall AGENT -> hostname is not fetched very often, so easiest would be to restart AGENT's service. It can be done using following commands in root terminal:
cd "/Applications/ESET Remote Administrator Agent.app" ./Contents/Scripts/restart_agent.sh  

@display3958023 The reason is simple. All in one installer is available only for Windows.  Information is available in the help of ESET Remote Administrator: https://help.eset.com/era_admin/65/en-US/deployment_scenarios.html?fs_local_deployment_aio_create.html
In case of a mac product, you can either generate an agent live installer script, or deploy the agent installer manually. Installation of the security software product can be then performed using a software install task. 
PS: I would strongly recommend to upgrade your server to ESET Security Management Center V7, which was released more than a year ago. 

You can download the standalone mac endpoint installer at eset.com (download section). Specifically here: https://www.eset.com/int/business/endpoint-antivirus-mac/download/ 
Installation works in the way, that when you choose a product you want to install, agent will connect to ESET Repository (cloud download server), and will download and installed the respective product. You can cache installers by a proxy server placed in between, to optimize a network traffic. 
With regards to the appliance upgrade, instructions are available in the documentation: https://help.eset.com/esmc_deploy_va/70/en-US/va_upgrade_migrate.html 

There is a default dynamic group Problematic computers which is defined as:

That said, any machines that have a protection feature disabled will fall into this dynamic group.
Then in Notifications enable this one which you can customize, if needed:

Details are provided here, on the forum post: 
 

Then the only option will be to remove the agent, and try to install it again. 

Hello Jirka,
For the first problem, I would first apply "reset the RD sensor database" task, to validate whether the white-list is working (as once reported the data are kept, even in case the RD sensor whitelist is actually working). Alternatively, I would uninstall the RD sensor at all, if it reports too many false positives.
With regards to the second problem, I would recommend to contact your customer care, as the error is generic, and does not give is exact reasoning for what might be the failure. 
Regards,
Michal 

@OrthoC Ok, so no "care-less" but "effortless"   We are working hard to design applications that will be simpler and would require fewer clicks, fewer steps, and fewer time in general to work with them. And automation is one of the paths we will for sure follow. This exactly shows us, how important this is! 

Thank you for the idea. I agree, it might be beneficial. I will discuss it with relevant people. 

Hello @Cruz This is a common request, that is being tracked. However, as of now, it is not yet confirmed for the scope of the version 7.1. I will verify, whether it´s still doable. 

You are right, the policy is "buggy", as it by default it includes also default rules (when you click on the " Show built in (predefined) rules" checkbox in the bottom they will be shown). I will ask our team to change it.
As a quick workaround, you should either edit the policy, and move the rules to the top (above the default ones). Or disable the predefined rules. I am sorry for the inconvenience. 

Thank you for the idea. I agree, it might be beneficial. I will discuss it with relevant people. 

Could you please provide logs located in directory %temp%\eset\ (i.e. in temporary directory of user that executed installer)? This specific error means that it was not possible to find installer matching requirements. Most commonly when in case:
version of product is no longer available (if version was explicitly requested when configuring installer) operating system is not supported by selected product (desktop vs. server products) ESET repository servers (repository.eset.com) are not available. Access might be blocked by other security-related software, or HTTP proxy configuration might be required.

@andy_s We will track this as an improvement request, towards the future versions. Issue is, that the "upgrade" itself is handled by Endpoint (in case you execute scan and select option "shutdown after scan"), and Endpoint does not initiate agent wakeup to report scan completion. It simply triggers shutdown, before the result is replicated.
Maybe, if you are willing to, can you explain why are you shutting down the machines? Is it to save power over weekends, or? As there might be different way how to achieve that. One that will report "success" would be a run command, with a respective windows shutdown / with delay, as task would report "Success" not in the moment of task execution, but on the moment when it contacted WMI provider with the command the reboot. If system acknowledged, it will report success.  Also, out of curiosity, what is your replication interval?

Any chance it resolved itself automatically after a time? We are currently experiencing issues with license synchronization, which is targeted by release that is rolling out this week.

Hi Paul,
Have you tried also with the latest version - 6.7.876.0 ?
There have been a couple of changes regarding MacOS compatibility. 
Thanks

There has been support for cloning implemented in ESMC, which means this scenario should be handled automatically if properly configured, without executing mentioned task.
Once machine was cloned, new Cloning Question for ESMC administrator should have been created -> until it will be resolved, cloned devices won't be able to communicate with ESMC and thus not able to reset itself. There is possibility to resolve it in a way that every other clone of specific device will automatically results in creation of new devices, as if reset cloned task was executed. I would recommend to check whether there are any cloning questions available -> they should be accessible through client details of "master image" or in status overview in ESMC console.

@Markwd Hello, there are two reasons. Anti-theft in consumer is focused on device retrieval, not on the data security (no possibility to wipe the disk on the device). Also, the implementation capable of tracking screenshots / photos of the users, might violate a lot of corporate laws / regulations. If Anti-theft is introduced into the business versions, it will have to behave differently. If I can ask you a question, what kind of a problem you would like to solve with it? Would it be intended for device recovery, or more a data removal / prevention of misuse ?

There are multiple methods: 
You can click on the "red" part, and drill down to see the list of machines with outdated agent You can navigate to the dashboard "ESET Applications" check table "outdated applications", locate agent, and drill down to get the list of all machines You can alternatively create a DG for not having a specific version of Agent installed (all others will be outdated). I would recommend to use the first / second option. 

Hello @Pinni3. To get to your points: 
For that purpose, we allow nested dynamic groups. Meaning you have your 30 static ones, each one of them could have nested dynamic groups. Our you want to set it in a way, that you for example put the DG under "all" but then say that it needs to be only in the following static groups. Challenge is, that DG is evaluated on the Agent side, and Agent does not always know, in which SG it belongs to (if you move a client, it will need to recalculate all policy assignments for example). Therefore the nested concept.  We are already tracking improvement for that (Internal reference - IDEA-1100) We are working on better auditing changes, to track who / what / when / how was done. (internal reference - IDEA-1371 I am not completely sure what´s the problem here. Purpose of ERA proxy was just to aggregate the data, but at the end it was sent to ERA server, so the amount of DATA sent is not increased when Proxy was deprecated. Just the ESMC server handles more connections directly, due to a changed replication protocol. Also, AFAIK we have bigger installations than 10k on MySQL. Maybe @MartinK can provide some more information on this.