michalp

Most probably "Recent update attempts failed" alert was initiated by Agent and not by EES. Next time, you can verify that by clicking on the alert, then you will be redirected to Alerts view and then by looking at Product column, you will be able to identify source of the alert. Agent updates modules that are used for configuration purposes of managed products. This update interval is controlled by policy ESET Remote Administrator Agent -> Updates -> Update Interval. Default interval is set to every 6 hours. If there was some problem with update, then the alert will be generated. The alert will be cleared, if next module update will succeed. Exact error code is in Agent trace log on a line that starts with "PerformUpdate: UpdPerformUpdate failed with error: ". From that number, I will be able to tell exactly what was the problem.

OS up to date check is done in 10 minutes after Agent service startup and then every 17 hours (this should be similar to interval used by Windows Update, on Mac and Linux interval is set to 24 hours). If Agent detects that system is out of date then next re-check will be done in 17 hours or after Agent restart. This should explain why out of date status is shown for a long time and Agent restart helps. There are two possibilities to change this behaviour: 1. Set up client task Operating system update on a regular schedule or execute it on demand. This task will install required updates and afterwards it will immediately execute update re-check. 2. Create policy to suppress Operating system up-to-date state (ESET Remote Administrator Agent -> Advanced settings -> Operating System -> Report if operating system is not up-to-date). Up to date status will be no longer monitored by Agent, but it will still be monitored by EES (same interval as virus signature database). We will look into changing default behaviour for OS up to date check by Agent in future ERA release.

Yes, if you want to use proxy for activation and updates, then set policy: ESET Security Product for Windows -> Tools -> Proxy Server. Don't forget to create similar policies for other products that are in your network, including Agent (ESET Remote Administrator Agent -> Advanced settings -> Http Proxy) as other products may need to communicate with activation servers and download updates.

According to the log, hostname that you have put in Agent installer can not be resolved (No such host is known.). Can you ping it from command prompt?

Action center (Security center) in Windows pushes notifications about health status (good, poor, not monitored, snooze) for specific security providers (antivirus + anti-spyware, firewall, updates) to ERA Agent by defined API. This information is usually pushed immediately and Agent will produce logs. If some of the logs are with high severity (e.g.: poor health status for firewall), then out of band replication will as soon as possible deliver them to Server. Unfortunately Action center does not exactly map states that are shown in dialog itself to health statuses that are pushed to agent. For example intentionally disabled firewall with Action center set to not monitored, will still push poor health state to Agent. Or completely disabled Action center will push poor states for all security providers. In this cases only possible solution would be to create policy as rcraig said earlier. To force recheck, Agent service restart needs to performed. In case of jimwillsher, that error notification was not cleared is either caused by Action center still pushing this to Agent or there is possibility of not correctly replicated information. We will try to look at it.

If you have installed ERA server through bootstrapper with enabled HTTP proxy, there should be automatically created policy for group 'All' that tells installed EES to connect through HTTP proxy. This includes activation process. I am not sure if EES reads Windows Proxy settings but definitely it can be configured through policy if you are running your custom HTTP proxy setup. Enabling access to https://edf.eset.com/edf on port 443 should do it.

What is in the agent status log located at: c:\ProgramData\ESET\RemoteAdministrator\Agent\EraAgentApplicationData\Logs\status.html ?

Agent itself tries to verify its peer certificate. If agent is not able to verify its own peer certificate, then error "Peer Certificate is Invalid" will be generated to status log (status.html) and if possible, sent to a server. My guess is that Agent certificate (new one) was signed with different certification authority than server certificate was signed with. During deployment you have used new Agent certificate and original certification authority - this is correct way because original certification authority was enough for agent to verify server certificate and on the other hand, server was able to verify new agent certificate as it has all certification authorities in database. After first connection was successfully established, all trusted certification authorities from server were replicated to agent and from that moment agent was able to verify its own peer certificate and clear the error.

Right now it is not possible to hide or remove peer certificates from web console. Peer certificates are stored in 'tbl_certificates' table. There is column 'removed' which controls whether that row will be displayed in web console. Putting '1' instead of '0' will hide specific certificate record. Doing this change manually will skip internal mechanism in ERA server that records changes of every static object in database. For this specific case and your ERA release, it should be safe. But do it at your own risk.

Some previous failed Agent installation caused this. Please run ./Agent-Linux-x86_64.sh --uninstall that should clean up any old files. Then run installer again. If there is no password for agent certificate (.pfx), then --cert-password= parameter is not necessary.

Please make sure that https://edf.eset.com/edf is accessible from a computer on which EES is installed. You can try access it with web browser, some XML file should be returned.