MartinK

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.

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.

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?

The firewall is not a part of ESET Endpoint Antivirus. You must install ESET Endpoint Security if you have a license for it.

Thanks for letting us know. First part is considered as an issue and should be targeted. Second part will be discussed as an possible improvements, which seems to be legit.

From description you provided it seems, that the same license was added into console using two methods:
Added license by it's key, either manually in the console or even during deployment of console itself (indicated by key icon) Added license by EBA accounts (indicated by EBA account and person icon in the list) Solution to this might be to consolidate this list. I would recommend to first:
Add the same license using your EBA account, just to verify it will work Remove original copies of the same license, i.e. the one tied to old/unused EBA account and the one entered by key Correct existing activation, deployment and installer tasks, ad they are most probably referencing licenses that you just removed - tasks and installer will be marked as invalid and won't work until they are updated with proper licenses Removing and re-adding licenses won't have any impact on products functionality (they will remain activated) but new deployments and activation might fails from the console in case tasks won't be updated after license re-adding.

From description you provided it seems, that the same license was added into console using two methods:
Added license by it's key, either manually in the console or even during deployment of console itself (indicated by key icon) Added license by EBA accounts (indicated by EBA account and person icon in the list) Solution to this might be to consolidate this list. I would recommend to first:
Add the same license using your EBA account, just to verify it will work Remove original copies of the same license, i.e. the one tied to old/unused EBA account and the one entered by key Correct existing activation, deployment and installer tasks, ad they are most probably referencing licenses that you just removed - tasks and installer will be marked as invalid and won't work until they are updated with proper licenses Removing and re-adding licenses won't have any impact on products functionality (they will remain activated) but new deployments and activation might fails from the console in case tasks won't be updated after license re-adding.

I would recommend to start by mentioned SQL and modify server_identificator in the table tbl_servers, but I am not sure this is actually enought for enrollment of mobile devices, but at least is should not breaking anything. Also note that hostname present in this DB table is shown in generated reports.

It is hard to evaluate risks as it depend on how management console will be used and how access rights are configured there, but what you can expect is that once device is managed remotely, user of console will possibly have administrative access to your device, as security products tend to have access to system and all files (for purpose of scanning). In terms of macOS, it technically means that remote administrator will be able to perform actions that normally only root user can. Possible actions might be limited for specific console users, but there will still at least one administrator that will have full access, which you might consider as an risk in case you have no visibility nor control of how access rights are configured in the console.

I would recommend to start with following MDM troubleshooting guide: https://support.eset.com/en/mdmcore-troubleshooting-65-and-later
It should point you to steps or at least criteria that certificate has to meet in order to be used with recent Apple devices.

Could you please check ESMC/EP trace log for possible hints? Can you verify that service "eraserver" or process ERAServer are actually running? After update, there might be some time during which console is not able to connects - during this phase, database migration is performed, but it should not take very long in case you do not have huge database size/content.
Also you have updated ESMC to EP in existing appliance, or upgrade using "appliance migration" was used? If first is the case, how old was original appliance? If it was much older, there might be possibly issues with dependencies.

Actually problem was in dynamic groups evaluation as described in my previous post. Logged users were reported correctly, but it was not possible to create dynamic group with required conditions (negate condition on empty list).

Have you also tried what happens after system reboot but before users logs in?
When users are leaving computer, do they actually log out, or they only lock screen? There is also possibility to create report with "Computer name" and "Logged user name" to check what is going on, but my guess is that computer will be still reporting last logged user.

It should be possible to create such group but I was not able to verify it. There are multiple options, but you may try to configure dynamic group template as in screenshot:
 

 
EDIT: dynamic group does not work in ERA 6.4
 
Once this dynamic group is replicated to AGENT, it is evaluated automatically and should detect change in list of logged users almost immediately as it is listening for system notifications. AGENT will be joining and leaving dynamic groups autonomously without active connection to SERVER -> if you attach specific task to this group, it will be executed even if computer is offline. I guess it is no surprise that you won't see offline computer joining/leaving dynamic group in Webconsole as this information requires working connection to SERVER.

Just a note that this issue should be resolved with version deployed recently.

This seems to be an common misunderstanding and we should probably improve communication to users so that it is clear.

In case of components upgrade task, you are actually selecting version of ESET PROTECT Server component, that you can actually upgrade to. In other words, in case your infrastructure is based on ESET PROTECT Server for Windows, you will be offered only the same or later version for the same platform. This version is later used for selection of compatible AGENT installers. So for example, as you have selected version 8.1.1223.0 as compatibility version, when this task is executed on macOS device, ESET repository is searched for latest AGENT version for macOS, that is compatible with ESET PROTECT 8.1.1223.0. which is currently version 8.1.3215.0. So the most confusing part is that you are actually not selecting version of AGENT to be installed, but just reference version used for compatibility.
 

Could you please provide standard trace.log from AGENT or possibly search it for more detailed connection errors? I do not see any obvious problem with deployment method you are using - in case no mistake was made during parameters processing, it should work. From provided status.html it is not clear why connection is failing, it might be network related, but also certificate related. As it seems that certificate of ESET PROTECT Cloud service has been accepted, it might be problem with AGENTs certificate -> in steps you mentions "same old file" next to certificates, but if it means that you are attempting to use the same certificates an you used with on-premise solution, that won't work -> devices managed by cloud service are assigned certificate generated by service itself, and that is only certificate that will enable your devices to connect.

Also note, that there is even simpler deployment method:
Download AGENT MSI file and install_config.ini (so called GPO installer) into the same folder Initiate silent installation of AGENT via msiexec command, but without product specific parameters (those P_***) Observe that installer properties are automatically loaded from install_config.ini, i.e. there is no need to copy them to command line

Actually it works in a way that only "supported" combinations are possible, so once you select more and more columns, there is less possibilities to chose from. So from technical perspective, it is "by design" as required combination is most probably not available.
What would be actually the use-case you are targeting by this report? Just to pair employees with devices that are no longer connecting?

Not sure I understand correctly, but filtering devices based on dynamic groups should be farily easy: just filter has t obe added to reports:

but there might be conflict with other settings, preventing use of such filter.

If my understanding is correct, you created installer where you included policy for EFDE? If so, it is actually expected behavior, as installer will just configure installed product to use settings from embedded policy, but to enforce settings, policy has to be applied also in console in a standard way. If so, solution would be to visit policies screen and assign required policy to groups or devices. In other words, policy as included in installers are intended primarily for initial configuration used until management agent is able to fetch policies and other properties from ESET PROTECT.

We will also try to improve communication of this behavior so that is it more clear.
 

Just to be sure, but by "only check in when they are turned on" you mean that do connect only once, after they are started, and another connection attempt is made after reboot? If so, I would double-check configuration of interval, especially in case "cron" based configuration was used.
Also as mentioned, troubleshooting of such device connectivity will be required, as issue might be also related to network configuration, which might prevent subsequent connections, especially in case there are other security/VPN products used or strict firewall configuration is applied.

Component upgrade task upgrades only ESMC/EP components, as is ESET Management Agent, ESMC Server and ESMC WebConsole, but it does not upgrade other, especially third-party components as is Apache Tomcat, Apache HTTP Proxy or MS SQL Server.

Thus benefit of performing manual upgrade using all-ine-one installer for Windows, or performing upgrade ot EP/ESMC Appliance using "migration" to new version, is that also third-party and and possibly other support tools are upgraded. Also note that manual upgrade is less prone to failures caused by environment issues, as are those network related, but also those caused by missing dependencies (for example minimal supported version of OS or database itself).

My recommendation would be to perform manual upgrade, as it is fairly simple from users perspective, and it offers more control. Also I would recommend to perform database backup before doing so, but hat should be case also for automatic upgrade.

Component upgrade task upgrades only ESMC/EP components, as is ESET Management Agent, ESMC Server and ESMC WebConsole, but it does not upgrade other, especially third-party components as is Apache Tomcat, Apache HTTP Proxy or MS SQL Server.

Thus benefit of performing manual upgrade using all-ine-one installer for Windows, or performing upgrade ot EP/ESMC Appliance using "migration" to new version, is that also third-party and and possibly other support tools are upgraded. Also note that manual upgrade is less prone to failures caused by environment issues, as are those network related, but also those caused by missing dependencies (for example minimal supported version of OS or database itself).

My recommendation would be to perform manual upgrade, as it is fairly simple from users perspective, and it offers more control. Also I would recommend to perform database backup before doing so, but hat should be case also for automatic upgrade.

Component upgrade task upgrades only ESMC/EP components, as is ESET Management Agent, ESMC Server and ESMC WebConsole, but it does not upgrade other, especially third-party components as is Apache Tomcat, Apache HTTP Proxy or MS SQL Server.

Thus benefit of performing manual upgrade using all-ine-one installer for Windows, or performing upgrade ot EP/ESMC Appliance using "migration" to new version, is that also third-party and and possibly other support tools are upgraded. Also note that manual upgrade is less prone to failures caused by environment issues, as are those network related, but also those caused by missing dependencies (for example minimal supported version of OS or database itself).

My recommendation would be to perform manual upgrade, as it is fairly simple from users perspective, and it offers more control. Also I would recommend to perform database backup before doing so, but hat should be case also for automatic upgrade.

Could you please check state of ESET Management Agent installed on the virtual appliance? Any chance you already tried to reboot whole appliance? Also was there any service interruption or operating system changes performed on a date that management agent connected for the last time? Previously we have seen that operating system updates or even changes of timezone/time o machine could result in this state.