MartinK

As mentioned, EPNS service connectivity is unrelated to issues you mentioned - EPNS in this case is used to wake-up device, used for example to make modifications to device faster (i.e. executing ASAP task sooner than deice would connect depending on it's connection interval) - I guess communication to epns.eset.com was blocked in this environment which seems to be indicated by 403 response? In case issue with 2 devices still persist, I would recommend to double check there are no "clones" in the console. If no, troubleshooting guide: https://help.eset.com/protect_admin/90/en-US/fs_agent_connection_troubleshooting.html provides more hints - .e. checking status.html log might provide quick status, especially whether AGENT is actually running and whether it is attempting to connect to correct "destination".

If it helps, it should be possible to request configuration from all devices using one task (manually created, even with limitation to export only configuration of security product) but be careful that depending on size of such configuration, it might generate network traffic and it might increase database size, especially when executed repeatedly in larger environments. But regardless of that, inspection of rules will have to be made manually.

By stacking I meant hierarchy of dynamic groups, for example as is by default for specific groups: Such hierarchy can be created manually when creating new groups, or using "drag-and-drop" for existing groups. As an result, only devices matching all groups/dynamic group templates will be part of "deepest" group. All group has it's own template in this case, which make is more readable and easier for verification.

Indeed that is a reason why it is implemented in this way, but on other side, we are more and more seeing issues with WMI, so it might happen that on systems where WMI is not fully operational, it will take much longer time until list is updated.

I would definitely recommend to create two separate dynamic groups/templates and stack them - it would be more transparent. Regarding second part, which should include only devices where no user from specific list of logged in, I think something like this: should work. "Negative" design should make it work even in case there are multiple logged-in users reported, but this would have to be tested...

Actually list is not updated upon each connection, but rather when AGENT receives notification from operating system (via WMI) that there are relevant changes. So in case WMI is operational, and AGENT is connecting to management console, it should be almost instant.

I would recommend to open support ticket to be sure. It seems there might be some issue with upgrading caused by previous upgrades. Solution might be to just uninstall and install it again, but that might have some consequences so I recommend to ask support for assistance.

Hello, we were considering this when renaming products and somehow concluded, that "File server" in this scope is still more suitable - it is not a role of the server itself, but it somehow presumes that former ESET file Security / ESET Server Security is used on such servers. But we will most probably rethink this...

could you please check "installers" subdirectory of all-in-one installer for file named like this: apache-tomcat-9.0.54-windows-x64.zip? It is actually standard/official tomcat installer to be used by all-in-one installer and it can be possible replaced with later version to be used for upgrade. In case upgrade of tomcat will be still disabled, could you please specify history of you environment in terms of when and how was initial version of tomcat installed? Was it clean installation of ESET PROTECT or it is being upgrade from previous versions?

Virtual appliance uses standard/official CentOS7 package to Apache HTTP proxy (package named httpd) and it is definitely recommended to update it, including whole operating system using standard mechanisms. Just be aware that CentOS7 (and RedHat) are backporting security and other bugfixes into package without changing versions, that is why version 2.4.6 might be confusing, but it will most probably contains all security fixes it was affected by. It can be also verified in changelog of this package once system is updated. Following command will list changelog of relevant package: rpm -q --changelog httpd where specifically CVE-2021-44790 was fixed in 01/2022.

There are multiple reasons why this might happen: client task "Reset cloned agent" task is executed on this client ESET Management Agent is completely reinstalled (uninstall + install) on this client hardware on this devices changes in a way that it is considered as an new device - but this would notify user with question, with exception only in case machine is marked as "cloning master". Could you please check none of those is relevant for this case?

Mentioned error indicates some kind of "access denied" error, which is suspicious as ESET repository servers are not using authentication at all. Is it possible there is some kind of HTTP proxy or firewall that could possibly filter HTTP traffic and possibly results in such errors? ESET repository servers are located on various locations (datacenters) across world, and also time to time it might happen that public cloud providers are used to host files (CDN) - any chance there is some kind of destination filtering that could fail for specific IP addresses or target geo locations?

Would it be possible to check there are any crash dump present in directory /var/opt/eset/RemoteAdministrator/Agent/Dumps (*.dmp files) and if so, provide them via PM for analysis? In case anonymous statistics are enabled for this device, it is possible that crash dumps were already processed, but we will need name of the file to pair it with this case. If so, name of the *.dmp file will be mentioned in trace.log of AGENT (even when default trace logging verbosity is set). If providing such data is not possible, I would recommend to open standard support ticket, as we will definitely need more details. Also are there any other symptoms, or AGENT crashes just during startup and it works normally afterwards? What versions is it actually?

Any chance you are using technologies like Umbrel or OpenDNS? Asking as there is a known issue reported by such customers, that they do have similar issues, and those are probably not resolved yet. Symtopms are probably similar, except that I am not sure whether it behaves randomly or it never works in such environments...

It depends on your environment. I will double check but there seems to be no reports with our DNS infrastructure - so maybe there is just some DNS misconfiguration in your environment? Maybe firewall blocking access to DNS servers or some issue with DNS caching? Maybe just specific network configuration is missing DNS servers configuration, for example are there any differences between devices? Or maybe adding some generic DNS server to configuration (i.e. something like 8.8.8.8) might resolve this issue, but ideally it should work out of the box, i.e. either your internal DNS server or DNS server of your internet provider should be used in case everything is properly configured.

Most common error seems to be: Failed to resolve: g3mu6zkwvyzejjp6brvqaeceei.a.ecaserver.eset.com:443 which indicates that DNS resolving of this hostname does not work. Could you please double check that device can resolve this DNS name (using nslookup) in all possible network configurations, i.e. when device is on wifi/lan?

Unfortunately backup and restore would work only for identical version and installation of ESET PROTECT. In this case I have suspicion that even when DB version will be fixed (by running installer repair), still there would be a problem with other identifiers mismatch. I would recommend to perform whole migration from original servers, using steps described in here: https://help.eset.com/protect_deploy_va/90/en-US/?va_upgrade_migrate.html. If those steps were followed, I think problem might be that VA was configured prior to DB migration (which is explicitly mentioned in #2 step as to not be done).

Could you please try to run installer from terminal, where LANG environment variable is set to en_US locale? I.e. to value like this: LANG=en_US.UTF-8 Seems there might be a problem with "C" locale, even workaround for this was added long time ago...

Could you please provide output of "locale" command executed with user you are running installer? from provided logs it seems there is just a problem with fetching it from system/terminal configuration.

Could you possible describe of what steps were made during DB migration? Asking as I cannot imagine how standard migration of database would result in this state. New entries in console are created when: ESET Management Agent is reinstalled -> new installation would results in new entry in the console After execution of client task "reset cloned agent" is executed or after significant HW changes are detected on device but I am not sure how it worked previously. But still I would expect it to be independent from DB version, except that there might have happened something that broke environment during migration.

It should be possible to do such a group, but I would recommend to split it into two separate ones: one matching devices with requested name. Just be aware you won't be able to use one "field" multiple times in a template definitions, so instead of "contains" filter type, you will have to use something that lets you to define naming convention in one filter - i.e. either "regex" of "one of" filter types. There are multiple alternatives of "fields" to be used, for example there is also "Device identifiers" category which offers various device identifying properties. second matching devices requiring restart. In this case, just be aware different product versions or even product types might report different functionality status, so you will have to list all of them - easiest is to check what are devices actually reporting and use it in a filter. Once such separate groups are created and it is verified they do work as expected, you can achieve "and" of those conditions by nesting dynamic groups.

Unfortunately there is an glitch in this latest version detection present in recent versions of the console - but there is no need to be afraid it would install wrong product or it would change anything in your configuration: problem is just visual and in the console, as both ENG and JPN variant are identical as this product has only one multi-language installer.

Downtime time depends on size of your environment and especially amount of data stored in the database, so it is almost impossible to guess. In case of smaller environment (lets say under 100 managed devices), it might be just a few minutes, especially in case there are enough CPU/RAM/HDD resources available with reserve as upgrade will consume more resources than regular service.

In this case, what is suspicious in logs you provides is this section: 2022-02-09 09:50:46 Information: CDatabaseModule [Thread 7fba899c0740]: CDBSetupperBase::PerformUpgradeIfNecessary: Processing log in ETL:QOS_NETWORK_EVENT 2022-02-09 09:50:47 Information: CDatabaseModule [Thread 7fba899c0740]: ETL CLogsETLMapper: Starting plan for logtype: QOS_NETWORK_EVENT - number of logs:44178 2022-02-09 09:52:02 Information: [Thread 7f1ca4d56740]: Loading ESET modules from /var/opt/eset/RemoteAdministrator/Server/Modules/ 2022-02-09 09:52:02 Information: Kernel [Thread 7f1ca4d56740]: Local time is 2022-02-09 17:52:02 2022-02-09 09:52:02 Information: Kernel [Thread 7f1ca4d56740]: InstallConfiguration: ProductLine: era 2022-02-09 09:52:02 Information: Kernel [Thread 7f1ca4d56740]: InstallConfiguration: ProductVersion: 9.0.2144.0 which indicates that PROTECT service was interrupted during process of database upgrade. In this case it was fairly soon after it actually started. In case it was not made intentionally by user of operating system, most common issue resulting to this state we are aware of is possible insufficiency of system resources. Especially database server might consume more resources than expected during this phase. Is it possible this might be the case? It is hard to estimate as we do not know the details and from logs it dies not seem to be large environment. Any chance OS logs contain more details (for example OOM might indicate process was killed due to extensive use of resources) or possibly crash reports of our "ERAServer" process during this phase? It seems that process was failing repeatedly but there are no crash reports in our logs.

Any chance you checked logs for more details? During upgrade, it is fairly normal that user is disconnected from the console in a moment when ERA/ESMC/PROTECT server is stopped due to upgrade, but it should definitely start afterwards. What might be confusing is that resource-consuming part of the upgrade process is actually executed during first startup of newly upgrade server, but during this phase, connection from the console are not possible which might lead to a confusion and often even to user-enforce interruption of this process. Also you mentioned "after upgrade of the OS" .. does it mean you have made some upgrade of your linux environment? If so, could you please provide more details of this environment - I can imagine that significant jump between major releases of linux distributions might cause such issues, but it should not happen with regular system updates...