MartinK

Unfortunately I do not see anything suspicious, but I am not sure such modification of installer won't cause problems. From logs from client device, it seems as if configuration was somehow wrong -> especially certificate might be either completely missing, or it just has wrong password. This might be result of script modification, as parameters are passed to AGENT installer in a way, that configuration file install_config.ini (generated by installer script) has to be placed in the same directory, as AGENT installers - and I am not sure this will work in case source of the AGENT installer h

I was referring to web interface, which can be enabled also via terminal (see documentation). In case enabling it and accessing from remote device won't be possible, there might be another alternative to use command line interface for manipulating with (documentation). But regardless of that, I just realized that this topic is in "Remote Management" sections, which probably means that you are using ESMC/PROTECT to manage this product -> if so, easiest and recommended way to configure product is to create configuration policy in management console with required HTTP proxy and assign it to

I would recommend to start by checking migration scenarios described in documentation: https://help.eset.com/protect_install/80/en-US/?migration_same_version.html But in short, it is not possible to migrate data between different database type (i.e. SQL Server to MySQL), but it is definitely possible to perform migration to newly installed ESET PROTECT appliance, without need to reinstall AGENTs. Just be aware that such migration would mean loss of all collected data and even configuration of console (i.e. various policies, dynamic groups, etc.) will have to be migrated, if possible.

Have you actually tried to set HTTP proxy parameters to product configuration via WEB interface it provides? I have not verified it, but that is most probably standard way how to configure product, and I would expect it to use those settings also when performing activation via command line.

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

In case nothing would help, I would recommend to check following locations where wrong hostname (localhost) might be located and breaking deployments: Hostname might be directly in the installer, i.e. later saved as P_HOSTNAME Hostname might be present in configuration policy that was embedded into installer - please double check it Hostname might be present in configuration policies assigned to device in console. I would recommend to pass all policies for ESET Management Agent and search for those that are applying hostnames.

Is there any reason or limitation, why you are not using standard web GUI of product to configure HTTP proxy there? In case local web gui is not accessible, there should be also possibility to configure HTTP proxy via policies from ESMC or PROTECT management consoles.

Checked logs and there are entries like this: 2021-05-06 09:37:38 Information: CRepositoryModule [Thread 163c]: CMetadataProcessorV3:http://repositorynocdn.eset.com/v1/com/eset/apps/business/era/agent/metadata3 is not synchronized (not exist in repository) and alternatives for each product, indicating that indeed synchronzation with ESET repository servers is not working. Could you please check you can actually download file from URL: http://repositorynocdn.eset.com/v1/com/eset/apps/business/era/agent/metadata3 on the same machine where EP service is running? Is there any firewall

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.

Just out of curiosity, could you please provide size of EP database? In case it took long time, it might be too large (maybe more than 10GB?), which might indicate problems with cleanup - especially in case there are no thousands of managed devices ...

Unfortunately not, as it contains only 3 minutes of data, and synchronization with ESET repository servers is most probably not covered, as it happens only once an hour ... but I have passed to others, whether they have not seen such behavior previously. But it might help to also provide trace log covering first minutes after service EP restart, there is a higher chance it will cover also possibly problematic part.

In case you are referring to notification named "Managed clients not connecting alert", feel free to edit it, or create clone and adapt it to your needs. Once configuration is opened: it should be possible to change 2-days interval set in filter by default.

Actually I was referring to EP Server's logs, located in C:\ProgramData\ESET\RemoteAdministrator\Server\EraServerApplicationData\Logs in case of EP for Windows, but in case there are only clients that are not able to connect to EP, it might also explain why version check is not working as intended. From provided logs it is fairly clear that AGENT on client devices is not able to connect to EP because of DNS-resolving issue - could you double check that hostname as was printed in logs is correct and can be actually resolved to IP address on client device?

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.