MartinK

What we can see from log is that AGENT's certificate has been revoked, which technically means that this certificate can no longer be used. Not sure what were you trying to achieve by removing/revoking certificates, but seem there are still AGENTs using those certificates.

Is it possible to configure snmpwalk so that it will be more verbose/more specific of where problem is? This format of SNMP notification has been used by ESET for many years and I don't remember any similar issue reported. Is there any obvious problem visible in wireshark capture in comparisson with other SNMP traps? I would recommend to open support ticket, as this issie seems to require someone skilled with SNMP. Please attach also mentioned wireshark capture so that it can be analysed.

First of all, I am not sure whether tou correctly disabled reporting of non-ESET applications. Just to be sure, unassigning configuration policy is not enouth -> it is required to assigne policy that explicitly disabled reporting of non-ESET applications: otherwise AGENTs will be useing last cofiguration value, which was "enabled" in this case. As you can see from DB size report, most of database size (~2GB) is taken by exported configurations. Are you using this task, or those logs are renmants of older ERA release, that procuded this type of log automatically for problematic computers? I would recommend to check whether this table grows and if so, disable task that could possibly request configuation export automatically (i.e. task assigned todynamic group). What is really suspicious is amount of "Agent deployment task" logs. These are produced during remote installation of AGENT. Have you extensivelly used this type of task? Please verify there is no task running regurarly. I would also recommend to remove remote deployment task if no longer used, as it may help during database cleanup. Regarding peaks during midnight - they are caused by database cleanups, during which are received logs not processed, and that is why mentioned queue grows. Seems DB cleanups are extremely slow, which may be caused by size of database or perfomance problems. What could possibly help is increasing RAM of machine - as you pointed out on screenshoot, there is no free ram during cleanup. I would also recommend to check other possible performance bottlenecks. Regardless of previous, there is definitelly not as much data as is database size. To decrease size of database file, you need to shring database. I would recommend to consult this with manual for specific version of SQL Server you are using. In most cases, simple restart of DB may result in automatic shrink of database size.

Could you please verify that mentioned IP address is correct? It is possible that reported IP adress is not corect and therefore configuration interface https://192.168.22.104 is not available -> it has to be IP address or hostname of appliance. As already mentioned, before you can use ERA and its Webconsole, appliance has to be configured. Configuration is performed through web browser and configuration page is hosted by appliance itself, using self-signed TLS certificate, which may be problem in case strict configuration of browser or HTTP proxy is used.

You are right, your PROXY is missing CA certificate that was used to sign SERVER's peer certificate. You have multiple CA certificates? Or you completelly missed this parameter during OVA configuration?

Coul you please providee more details of deployment scenario, especially whether computer you mentioned as has ben created prior to installation (either manually, imporeed or using AD synchronization) or it was created automatically after AGENT was deployed -> AGENTs installed by bundle installer should appear in Lost&Found group or any other static group if specified in installer creation wizard. Computer with unknown state - does it report any data, for example operating system name, installed application and so? Or it is without any data? You mentioned that there seems to be everything correct with deployed AGENT - does this mean you checked status.html log and AGENT reported successfull connection to SERVER in recent time? I would recommend to search for newly appeared device in static groups hiearchy matching parameters of your computer, even in case it has different name -> it is possible that name reported by AGENT was not correct during installation, which may have resulted in creation of device entry with unexpected device name. It is possible to create reports based on IP addresses or MAC addresses of network interfaces if it will help to locate such device.

his specific error, it means that HTTP download operation was interrupted, which has many causes, including failure during transmission, failure of HTTP proxy or even failure on ESET server - which may have been caused by temporarily overloaded services anr maintenance. Is update failing regurarly, i.e. every update fails? Agent should update itself every 6 hours by default. In case failure is not repeating very often, you can ignore this issue. In case it will repeat regurarly, please check HTTP proxy or other components that may be interferring communication.

Non updated operating system may be reported by multile sources. You have not specified which one (it is part missing from screenshot), so I suggest to disable all of them. Create new configuration policy for AGENT and security product you are using (EES/EAV) and search for respective settings. In case of AGENT, it is in section Advanced->Operating System and in case of EES/EAV in section Tools->Microsoft Windows Update.

There is a known issue kb5949 with certificate validation on OS X: Not able to confirm from provided logs, but highly probably. In case it is this issue, you will have to create new certificates so that they can be used on OSX -> this means creating new CA certificate, SERVER certificate and AGENT certificate.

SNMP traps are sent by ERA to localhost, therefore forwarding has to be configured, as described in documentation. Regarding your issue, it seems that notification is not triggered at all. I would recommend to tweak it using email as it is much easier to setup and diagnose. In case you have properly set SMTP server parameters (and you are able to receive test email), it is almost 100% that notification is not triggerd - is it one of predefined, or newly created?

It should not behave like this, but maybe license has changed since you installed previous version? @MichalJmay be able to confirm what is expected behavior.

When you created mentioned ERA task (I guess it is software installation task), have you specified license? Selecting license will instruct ERA to activate product once it is installed (or upgraded in this case) - maybe that is reason for this behaviour.

If I recall correctly, AGENTS v. 6.1 defaulted to 20 minutes -> this interval has been changed as a part of "modules" update and that is why even those old AGENTs should be now connecting in minute interval in case they are updating from ESET servers and interval is not explicitly specified by configuration policy.

Installing AGENT remotely (using remote install task) requires client machine to have open ports for remote management. This may be disabled completely, or for specific users because it is potential security hole. That is most probable reason why deployment timeouts. Details can be found also in ESET KB3630. In case you are able to install AGENT, but it is not connection to SERVER, you should check remote installation task configuration, especially "server hostname" whether it is correctly configured for your environment. Installing AGENT manually does not require such permissions -> only connection from AGENT to SERVER is required, which I guess is not blocked.

Seems that task timeouts. Could you verify whether there is at least attempt to connect to client machine? In case it cannot reach client machine, it may result in network timeouts. Alternatively downloading AGENT installation on client machines may take so long that task is marked as timeout. Maybe enabling full trace log verbosity will provide more information if filtered for "RemoteInstallation".