MartinK

This was log captured just 7 seconds after AGENT service startup and that is why most of the details are missing. This itself is suspicious and might indicate problems with stability or correctness of installation -> AGENT is probably not able to start and thus not connecting to ESMC. Please attach also trace.log which might show at least basic error message and confirm whether AGENT service is able to start or it is restarting itself due to some configuration or system issue.

I would have to verify by my self to be sure, but reason is probably that negation of specific condition is not very clear and it can be easily misunderstood. For example condition Installed software . Application version doesn't contain 7.1.2053.0 will be probably always true, as there will be also ESMC Agent with different version in list of installed applications. In case of version it makes no sense to use this kind of expression. My recommendation is to use positive conditions inside group definition, and instead negate result, i.e using NAND group type with following filters: Installed software . Application name = (equal) ESET Endpoint Antivirus Installed software . Application version = (equal) 7.1.2053.0

I would recommend to contact ESET support for this issue. I do not think there was any similar report to this time so more details of disk configuration might help improve ESMC components. Regarding problem with fetching dynamic disk details, from provided logs it seems that it is not fatal problem and there is some network problem, indicated by error "Connect failed". I would recommend to check whether client (where AGENT is installed) can resolve DNS name of ESMC server and whether connection to port 2222 is possible.

Unfortunately AGENT is currently not reporting NIC that is actually used for connection to ESMC -> it reports list of all interfaces with list of all assigned IP addresses. What you see in main client's view in console is selected IP address that is considered as the one with highest priority. In most cases it means it is IP address of NIC that has highest priority on client machine. In case of multiple IP addresses assigned to this NIC, it should be primary IP address of it.

Indeed ping would probably fail as ESMC Appliance has enabled firewall which is blocking such request, but crutial fact is that client machine cannot resolve hostname. This is something that has to be resolved either by network configuration, or changing hostname/IP of ESMC servers in installers so that AGENT can actually connect to ESMC.

Relevant error in this case is: GRPC:Failed to resolve: ESET-INF01:2222 which means that AGENT is not able to resolve DNS name of ESMC server. Could you verify this hostname is actually correct. If so, I would recommend to check directly in client machine whether this hostname can be resolved using nslookup or possibly by ping. As a result of connectivity issues, AGENT is not able to fetch client tasks - which means it is technically not managed yet.

I would recommend to start by checking hint and requirements for remote deployment to work in our documentation: https://help.eset.com/esmc_admin/70/en-US/fs_agent_deploy_troubleshooting.html. It lists most common problems we have encountered and from our experience it seems that it covered all problems we received reports. There are specific settings required to be properly configured to work properly. Another alternative is to use standalone deployment tool (https://help.eset.com/esmc_admin/70/en-US/deployment_tool.html). It helps especially in case deployment cannot be performed from ESMC server directly, either due to network limitations or due to missing permissions (i.e. domain administrator account might be required for deployment to be secure).

As you can see, translation module 1708 is quite old as it is dated to year 2018. Could you please verify that your ESMC can access update.eset.com? Or on case of offline environment, could you verify HTTP proxy is properly configured? Updating mechanisms of ESMC is crucial to receive updates adding support for new ESET security products, including both translation of newly added status ans also configuration settings.

Task mechanisms is very simple -> it takes FQND of machine as reported to ESMC and changes device name in console to be exactly value of hostname that is reported as FQDN. Crucial in this case is what ESMC Agent is reporting to ESMC as FQDN. This can be shown in console in client details view in device identifiers section: as "Computer FQDN". Until this value is not corrected, renaming task won't behave correctly. As I mentioned previously, ESMC 7.0 Agents are not using any kind of reverse-DNS lookups, they just ask operating system for it's FQDN. In case system does not report correct value (or it is missconfigured, or it does not even have knowledge of it's FQDN), there is no way around, except disabling renaming task for those devices and rename them manually to match entries in domain.

Unfortunately there is no support for this. I would recommend to check whether it is possible to use some third-party syslog server that would be able to forward data to multiple hosts.

In case it won't help, please provide us versions of ESMC modules as shown in "About" dialog in console.

Unfortunately without any details, it is just guessing. As you have not even mentioned method you are using, I can only name most common problems: in case of "live installers", installer download from repository.eset.com is most common issue in case of "remote deployment" most common issue is miss-configuration of client machines preventing remote connection and administration in case of "manual" installation mos common issue is wrong configuration of agent, i.e. wrong connection parameters or certificates.

Value of kern.hostname should be actually used by AGENT so setting it should resolve problem. There is definitely no need to reinstall AGENT -> hostname is not fetched very often, so easiest would be to restart AGENT's service. It can be done using following commands in root terminal: cd "/Applications/ESET Remote Administrator Agent.app" ./Contents/Scripts/restart_agent.sh

It seems that AGENT is not able to recognize encrypted APFS partitions as encrypted. Only support for legacy filesystems was implemented in ESMC 7.0. Unfortunately I cannot give you any guarantees regarding fix delivery, but issue is now tracked as bug.

Is there any known method you are already using to fetch FQDN on those machines? For example some command line tool, shell command, etc.? Does output of any of following command: hostname hostname -f scutil --get ComputerName scutil --get HostName scutil --get LocalHostName sysctl -a mention value that could be possibly used as FQDN? We have already seen machines that were configured in a way that they were not aware of their's FQDN, it was available only on DNS servers, but that is problem for ESMC Agent which requires data to be available locally.