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.