MartinK

Management of MDM service, and also propagation of mentioned last connection times is handled by so called managing AGENT, which is actually ESET Management Agent installed on the same server as is MDM. So please double check that there is actually and ESET Management Agent installed and running, and especially whether it is correctly connecting to EP server.

Could you please double check that provided logs are from this problematic client devices? There seems to be different connection details, or more precisely those logs are probably from EP itself, not from problematic device. But regardless of that, I would recommend to check network connectivity, i.e. especially whether used EP is accessible on port 2222 from client device.

As you probably found out, most basic information is available in main dashboard, in the following section: which also offers possibility to manually upgrade outdated ESET components. There is also dashboard named "ESET Applications" which do provides more detailed view of how many and what version of ESET products are outdated.

Could you please double check problematic devices are connecting, i.e. they had chance to report status? If so, I would recommend to modify DG template in a way that it will use operator "AND" and "not equal" conditions, even it should be equivalent on first sight? Also please provide list of "IP subnetwork" values for all network interfaces (i.e. as reported by console for such devices) on devices that you expected to be present in defined dynamic group for verification of DG evaluation correctness.

Could you please double-check that Java actually used by Apache Tomcat is of supported version? We have seen similar issues with OpenJDK 16 (non-LTS) which is not supported as it introduced breaking changes. Alternative might be to explicitly configure Apache Tomcat (via it's configuration utility) to use Amazon Correto 8 Java.

Could you please provide more details of which reboot you are actually referring to? Asking as there are multiple scenarios where reboot might be initiated (explicit reboot task, post-upgrade reboot, post-OS-upgrade reboot) and each of them has slightly different behavior. Regardless of that, we are tracking these requirements, but there is currently no possibility to configure it. Explicitly requested reboot of the machine should provide at least basic notification to users, as you mentioned -> this has not changed for some time, but it does not provide user to delay or cancel reboot if requested by administrator.

Could you please provide more details of your environment? For example version of Java? We do support only LTS versions, so I would start by checking whether it would work with different Java version (OpenJDK11?). Also have you tested with different browser just to be sure it is not browser-related?

In case it stopped working suddenly, I would not expect upgrade of ESMC would help. As you have not made any ESMC changes, I would check configuration of SMTP servers, or possibly trace logs of ESMC where more detailed error might be indicated -> sudden change in functionality might be related to network, firewall configuration or maybe expired TLS certificate of SMTP server, etc.

Could you please provide more details of what type of migration you actually used? And did it involve also upgrade to latest PROTECT version, or you are using the same version as before migration?

I would recommend to open standard support ticket with ESET representative. This will require more investigation and logs will be required to be collected. From provided components versions it seems you are using ESMC Appliance: if so, upgrade should be definitely working without any issues, in case network connectivity to ESET repository servers is available and there are no OS-specific issues. Also is there any reason why you are updating to ESMC 7.2? Update should be possible even to latest ESET PROTECT 8.1

ESET PROTECT and AGENT will be trying to use persistent connection, but in this case it seems that it fails, and each time AGENT is connecting to EP, it opens new connection + the old one remains at least partially open. Could you please check, whether network components in-between AGENT and EP are capable of holding open TCP connection for longer time, even without activity (i.e. 5 minute interval means such components should not drop connections with 5minute inactivity).

Thanks for letting us know. We have been already reported this issue with "Parent group" selector, and as you mentioned, workaround is to select group after all other modifications are made.

Automatic upgrades do have grace period (2 weeks currently) and upgrades are distributed randomly during few weeks period, so It will take some time, but first upgrades should begin shortly (tomorrow it will be 2 weeks since release). Those periods are there for users that with to upgrade on their own and to reduce impact on network...

It is actually very straightforward -> when update that requires EULA acceptance will be detected in the network, following notification will be available in the console: for user that has permissions for managing outdated device. Accept now action will open dialog: with list of not-yet-accepted EULA documents, but we do not expect to happen this very often, as unification of EULA documents was part of this initiative, which means that most ESET products do share the same EULA document - especially those security-related. As of now, such acceptance is required only for products for Linux, where updates are available already.

Also note, that in case of ESET PROTECT Cloud, generally latest available ESET Management Agent should be communicated and installed as latest version. Unfortunately we are not communicating it explicitly, as is done with releases of on-premise ESET PROTECT, which we might improve in the feature so that it is clear also for users of cloud-based console.

ESET PROTECT webconsole is hosted by "Apache Tomcat9" server, so I would recommend to check what possibilities it offers to extend headers of hosted applications.

Renaming mentioned directory is actually last step in upgrade process (swap of previous and new version), so after manual renaming, it should be fine to use. But otherwise I am not sure what could be wrong - seems that something was blocking renaming of era.new directory, but this directory should not be used at the moment, so either Tomcat was running (even it should not have been) or extraction of directory was not finished yet - but in this case, we will check whether this can be improved at least in a way that directory will be copied instead of moved, and in case of failure, it will just fail to remove temporary file, instead of failing whole upgrade ...

Could you possibly report this issue just that is it not forgotten? Actually there has been changes you mentioned (support for ARM64 platform has been added) and therefore either new mirror tool or changes in ESET infrastructure will be required to resolve this problem.

Could you please provide more details of browser you used initially? Most commonly used browsers in latest versions should be definitely working properly...

This is indeed very suspicious - my lat idea is to test with different browser, or possibly without plugins in browsers, maybe there is some kind of incompatibility...

If I recall correctly, there were no changes in functionality, nor configuration between this and latest release of HTTP proxy, except that underlying third-party components (Apache https, openssl) were upgraded due to vulnerabilities/security issues in those components - but I do not recall any that were actually affecting functionalities used but this components... Also I am not sure why upgrade is not working as expected, but in case default configuration was used, uninstallation + installation of new version should do the trick. Even in case configuration was modified (for example by adding port and hostname configuration specific to your network), migration to new version should be very simple, as configuration file was almost not changed between versions...

Could you possibly check how predefined dynamic group "No security product installed" behaves in this case? Not sure how this group/template is named in your instance due to different language but it uses different approach for detecting products, which might be resistant to WMI or similar issues you observed, even that list of installed applications is not fetched using WMI so there might be different problem on the machine...

Could you please check EP trace.log for more details? In case EP service is not running, there should be different failure error, indicating connection problems. EP's trace log is located in: /var/log/eset/RemoteAdministrator/Server/trace.log accessible via SSH or possibly using Webmin interface, both of which has to be explicitly enabled. Also in case domain login is used, please double check machine is correctly joined into domain and connection to domain controller is available. As you mentioned 3 different deployment attempts, any chance you tested multiple different passwords? Just to be sure there is no problem with some special characters in password...

I would recommend to double-check network configuration and possibly firewall logs, as repository content should not be affected by licenses, i.e. it is possible that repository synchronization passed only just randomly and it is possible it won't be updated in the future ...

Please do not provide msiexec parameter to "Installation parameters", it is supposed to contain only custom properties used by installer itself. In other words, parameter "/qn" is not required at all, internal mechanisms will ensure that installation will be silent, that is standard behavior. But be aware that it won't be possible to upgrade AGENT using this mechanisms, could you please provide more details why you are doing so? Or it was just example?