MartinK

This indeed most probably means that communication do works properly, so there might be different issue. In case product is already installed, it is skipped during installation and thus it does not fail. Actually communication with different service is involved in this stage (ESET licensing servers), but regardless of that, previous check confirms it is not network related problems - so indeed there will be problem with selection of package suitable for your operating systems: we will check from logs, but only issue I can recall we had was already mentioned issue with server-based Windows systems with RDS services.

Feel free to send me those via private message. I would also recommend to open support ticket in the meantime, in case it will require more details to be provided.

Unfortunately there does not seems to be any obvious problems, so please provide us installer logs, that are located in directory: %temp%\eset = there should be directory "eset" in temporary folder of user that is trying to execute installer. In case multiple attempts were made, it might make sens to remove this directory and re-try again, so that only logs from most recent failure are present. Hopefully we will be able to identify source of the problem -> it is either incompatible package selection or problem with communication with ESET repository servers (http://repository.eset.com) - In case enterprise grade firewalls of HTTP proxies are used to access internet, please double check repository is accessible from servers.

I would recommend to open support ticket int the meantime as this might require more data for proper analysis, as there are various externalities that might have imact on this functionality. But in order to triage this issue, I would recommend to perform various experiments that might help locating the problem: I would recommend to test whether manual installation work on target machine when "Live installer" = BAT-script based installer works on target device, as this is the same script that is supposed to be executed remotely. As it is live installer, it will be downloading package from ESET repository, which might results in timeouts or download errors. Also it might be impacted by HTTP proxy configuration I would check whether Remote Deployment Tool can actually deploy package to the device. It uses the same remote access mechanisms, so in case Windows = it might indicate that remote machine is not properly configured and is rejecting remote connections required for deployment. Also please double check our operating system is updated - I am not sure whether such older appliance had actually support for SMBv2 protocol - it is possible that updated Windows 10 machines has no longer support for older protocols and thus rejecting remote connections. Prior to system upgrade (especially in case it was no upgrade for a long time) I would recommend to create virtual machine snapshot so that revert is possible in case of other issues. In case it won't help to point out the problem, trace.log of ESMC Server service might provide more details, but It seems this might be related to network problems. As deployments are performed sequentially, in case they are no longer starting, it is possible they are stuck in attempts to connect to one of previous devices. Service restart would probably resolve this until next stuck attempt is made...

Please send me those via PM if possible. Also please include your cloud identifier (visible in "About" in ESET Business Account portal).

Could you possible specify of what method you used to "upgrade"? Asking as there should be no such problem during standard upgrade methods, especially in case agent was connection prior to upgrade attempts. Agent should retain policies even when there is no connection to the EPC server, and the only situation where policies might disappear is when agent is reinstalled and not able to connect, or when it is connected to a different EPC server where no policies are specified... Also would it be possible to upload trace.log and status.html logs from problematic client? We would like to check what could be wrong. Provided error indicates some network related problem and it is not clear what could be wrong.

Would it be possible to check those "ping" from inside of appliance itself to possibly exclude network or firewall issues? Otherwise It would be hard to guess what could be wrong, but in case service is stable (i.e. that is is not crashing or something like that), I would guess that it is either network or firewall related. Not sure how checks are made, but it is possible that standard iptables firewall as present and enabled in appliance is blocking repeated attempts - but that would be probably case only in case very aggressive checks... Otherwise only suspicious in your screenshots are free RAM graphs, which indicates there is something with huge memory consumption, but hard to guess. Also in "top" output, I do not see main PROTECT service (executable named ERASever) so was it actually running? Could you verify it's uptime is as expected? Maybe it is indeed crashing due to huge memory consumption - unfortunately we are aware of a network "leak", which might be triggered during those availability checks -> it would be visible by slow memory consumption growth and leaking of sockets from the operating system.

Could you please provide more details of how the "red" status actually look like and which versions are you using? In case you are using EEA/EES for Windows 9.0, there was an security hotfix released today, and notification is most probably red because of severity, and that new version is not applied yet (it will be applied after reboot), even in case older version is fully operational, there was an issue that lead to hotfix, so upgrade should be applied as soon as possible to ensure minimal security risks. In case you meant "red" state of version check, red color indicates that you are not using latest version, and also that current version is no longer available = indicating that there was an security issue.

Unfortunately this seems to be hard to diagnose without detailed logs - from description it seems that is some more generic problem with upgrade itself, but in case PROTECT or ESMC Appliance as used, there is a minimal chance it will be related to it directly, but I would guess it might be related to data present in database or configuration of virtual machine in terms of available resources (disk size, RAM) - in case there is a lot of data, upgrade might take more resources than actually available and resulting in repeated failure or even in inconsistent state of database, preventing even another upgrade attempts...

Seems it is not clearly communicated, but it is most probably there just to be sure that you are using license used for activation of cloud instance, and not some other license as that would probably violate terms of use. But in case your original license was converted to cloud, there is no need to do so. In this case I have suspicion that something might have gone wrong - migration policy you downloaded from cloud instance actually reconfigures AGENTs to use new certificate (tied to your) and start connecting to new server. But it is possible that when this reconfiguration happened, AGENT was able to very was evaluate new certificate and send this information to original servers -> I would say this won't cause any issues, but please double check that those devices are actually actively connecting to cloud instance, i.e. verify there were migrated properly. Also once those AGENTs connected for the first time to cloud instance, they should receive CA certificate used for verification of certificate - this certificate was missing previously and that is why certificate was appearing as untrusted. Unfortunately from this description I am not sure what you mean. But regardless of that, cloud policies that are present from initial state = defeulat pre-generated policies are mostly not assigned to any groups, and also they are almost identical to those created in on-premise servers. You should be able to modify most of them (except those marked as locked), but my recommendation is to not modify those policies, and rather unassigned them and use your own if changes are required. This would let us to patch those policies later, if there will be such need - for example recommended configuration might change with new version of products.

Could you please clarify whether you are using ESET PROTECT on Windows or Linux? On Windows, different mechanisms for configuration is used, as there is SNMP support directly in operating system. In case of ESET PROTECT for Linux: we are unfortunately aware of issue with configuration and that is why we dropped support for it in recent ESET PROTECT Appliances (based on CentOS7), as mentioned in documentation for recent versions: https://help.eset.com/protect_admin/90/en-US/how_to_configure_snmp.html If I recall correctly, proper configuration was not found to this time - even that application part has not changed for years, there is definitely some problem, most probably related to permissions/access rights. PROTECT is technically invoking "snmptrap" command line utility, which is supposed to communicate with local daemon, and in case there are no errors reported in PROTECT logs it would mean that this commend is executed successful, just trap is not properly forwarded or dropped due to access rights.

Mentioned detection is network-based, so it will be blocking all such attempts, regardless of their target and possible impact or presence of vulnerability. Also log4j presence in ESET PROTECT was mentioned, without any further details - in case ESET PROTECT Appliance was meant, log4j present there (and not used by ESET PROTECT services) is of older and unaffected version.

Unfortunately there is not a dedicated manual for this environment setup. But from technical perspective, there should be no issue with such configuration: it is used internally and for testing. I would recommend to check following tutorial: https://support.eset.com/en/kb7812-install-eset-protect-on-linux-and-connect-it-to-sql-server-on-windows which provides step-by-step guide how to connect ESET PROTECT Server installed on Linux to an external MSSQL instance -> difference in your case would be "network" location of SQL Server instance (i.e. installer command line parameter --db-hostname).

Unfortunately we have identified this glitch in our version check functionality and possible resolution is in progress. Issues is tied to fact that those few problematic versions currently offer two methods of upgrade: either full upgrade to latest version as currently release, i.e. using MSI installers so called auto-upgrade of product, which uses different mechanisms with much smaller impact on traffic. Unfortunately such update package was not released for 9.0 yet and unfortunately version check currently evaluates latest version using second method. This should be happening only for specific older versions - once they are updated, version check should also change and start reporting latest version (9.0).

In case it is appliance, it is possible to use command line utility to do so, or you can connect from external device, but only if you disable firewall (which might disconnect you from the PROTECT console as it performs also port redirection).

I would recommend to open support ticket in case i has not been done in the meantime. Also could you please provide more details of what kind of environment this is? Is it ESET PROTECT Appliance? If so, there is possibility to deploy new virtual machine with migrated data in case there won't be any other solutions. In case appliance was deployed longer time ago, or it is completely custom server, could you verify "xauth" command is present in the system? It is responsible/user for generating XAuthority tokens that is the last message in the log. But to diagnose this issue, could you please check whether tomcat and eraserver services are actually running on the system? Or console is running and is upgrade, but login fails. In case eraserver service is not running, checking trace.log might provide more details. Also running installation repair by executing installer script: /opt/eset/RemoteAdministrator/Server/setup/installer_backup.sh --skip-license might helps, even it would be very rare - but at least it will possibly show different error mesage, especially in case script is interrupted or stopped with some external reason.

Would it be possible to provide more details, especially failure reason as shown in the console? There should be localized error message, but also "trace" message which might provide more details. In case both upgrade do fail, my best guess would be that: there is a problem with connectivity to ESET repository servers (repository.eset.com) or there is some generic problem, for example another installation is running, OS requires restart due to performed OS update, or maybe there is not enough disk space But regardless of that, there are multiple possibilities how to upgrade those applications, especially in case you have access to the device - for example using standalone installers that can be downloaded from ESET web page, but also using various installers that can be created in the ESET PROTECT console.

Unfortunately I am not sure there is better solution than to edit this value in the database of ESET PROTECT. It this is acceptable, I would recommend to check recent topic: where name of the table and field to be modified is mentioned. Even mentioned topic was for Windows/SQLServer deployment, it is the same for Linux/MySQL environments. Also note that this will change just default value in the installers and in various other places (name of the server in the generated reports) but it won't have any impact on certificates and connectivity of AGENTs, where migration has to be performed with caution, especially in case new certificates are not using wildcard "*" for hostnames.

Could you please provide more details of when do you see this error? When manual wakeup call is requested for those specific clients? OR when you trigger some task and "automatic" wakeup call is performed in the background? In case you see this error in console, or in ESET PROTECT Server logs, it might indicate that there are no data required to wakeup those devices stored in database, which might happen in case those devices are not connecting to the console, or they do have issues contacting EPNS service itself. Also note that wakeup call performs two independent wakeup operations, one of so called WakeOnLan which is supposed to start devices in case it is in sleep mode, and also so called EPNS (ESET Push Notification) which will trigger immediate connection. This requires previously mentioned connectivity to EPNS service from both ESET PROTECT Server and also AGENTs installed on managed devices (it is actually persistent connection to epns.eset.com either on port 443 or 8883).

I would recommend to open separate topic with this issue and possibly provide more details of what kind of error are you getting (ideally installer logs - EraAgentInstaller.log). Even adding support for this distribution is not in a plan due to it's market share, but it is very probable that there won't be any significant problems - generally systems with OpenSSL 1.1 should work except special FIPS variants which do mostly omit functionalities required by AGENT to be installed.

Unfortunately this is a known limitation. Problem is, that live installer for cloud console is never actually offline installer - method you used to pre-download installer packages is there just to simplify deployment on devices with limited connectivity, i.e. to reduce impact on network traffic. But installer itself requires internet connectivity to download it's actual configuration and other metadata. This includes configuration as present in console wizard, including HTTP proxy parameter = which means at at this moment, installer is not yet configured to use proxy from it's configuration and thus it will be attempting to use system-wide configuration to be able to fetch additional customer-specific configuration parameter...

Just note, that this will start to work only with alarms generated after this change: could you double-check you tested with some of the one ones, not those generated prior this modification?

You probably meant version 6 (i.e. new generation that is used till now, with different branding) and indeed it is not possible to migrate data from MSSQL to MySQL. So in case use of MySQL is requirement, only possibility is to use mentioned migration scenarios, or even just reinstall PROTECT server and point it to MySQL database in installer wizard. Just be sure there are backups and all data are exported and re-imported into new installation. Not sure I understand, but If migration scenarios are meant, there are no plans to do any changes. The same applies for databases as of now.

In case it is just one client (does it mean 1 device?), I would recommend to just re-install using EP installer. In case EP 9.0 is used, the same version of AGENT will be used and thus installation repair will work, i.e. it won't be even required to uninstall components prior to use of EP installer.

Could you possibly provide more details of what is meant by migration? From logs it seems that AGENT is missing CA certificate required to verify certificate of ESET PROTECT (Server) and thus not connecting. In the console, you see just a placeholder created probably during AD synchronization. What is actually method that was used to deploy or migrate this problematic device? Are there any other devices not connecting? Were there any changes in PROTECT SERVER configuration recently? In case other AGENTs are connecting, solution in this case might be to manually repair installation of AGENT and provide proper CA certificate to installer.