MartinK

Could you please verify it is not one of known issues in Windows 10, for example mentioned here: https://docs.microsoft.com/en-US/troubleshoot/windows-client/networking/mapped-network-drive-fail-reconnect Otherwise it is hard to guess what could be wrong -> run command just executed provided command as an LOCAL_SYSTEM account, i.e. as an system user, which might cause issues, but I was not able to find any specific ones - but I would guess it has something to do with permissions, especially in domain environments, where LOCAL_SYSTEM is commonly not authorized for network access. If this is the case mapped disks might repair/remapp itself when first used by authorized user, which would mean it is not actually working until user reopens it, which might cause issues in case mapped disk is to be used by other background services.

Could you please provide more details, for example type of database, method used for installation, are you trying to use your own database or the one (SQL Express) bundled in the installer? In this case it seems to be an error provided to use by ODBC driver, which might indicate issue with driver od DB itself...

Could you please provide complete command line (without sensitive details) you used for invoking EP installer? I have suspicion there is something wrong, either improperly escaped, containing special characters, etc, Unfortunately it is not clear from installer log what exactly is wrong.

Could you please clarify what product or package you are attempting to install? From description it seems you are trying to deploy ESET PROTECT Agent. If this is the case, there are various deployment methods available for Linux machines: Manual installation (see documentation) Deployment using so called Live installers, which is actually a script that has to be delivered to machine and executed. Remote deployment task: which will open SSH connection to target machine from our ESET PROTECT Server and deliver previously mentioned live installer for your. There is unfortunately no support for Linux or macOS targets when using Remote Deployment Tool. In case use of Live installer fails, please provide more details. In case it is not clear form console why deployment fails, please check also log file: /var/log/eset/RemoteAdministrator/EraAgentInstaller.log for more details.

What was actually reason why file was not possible to download using Chrome? That is actually what might point you the correct way, as from description you provided it seems to be that there might be some HTTP proxy used for accessing internet, and if so, also other applications has to be properly configured - this includes both Chrome but also ESET PROTECT Server itself, is the settings you described. Before doing so, I would recommend to verify with "network gyus" or possibly check HTTP proxy configuration as can be accessed in "Internet Options" of your operating system or Internet Explorer configuration.

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 has been changed -> could you possibly investigate this?

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 devices. If product is managed, is there any reason why activation from local terminal is performed instead of remotely executed activation task?

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. Complexity of redirecting AGENTs to newly installed ESET PROTECT server is not high, it requires just changes in certificates, but one has to be careful with proper order of steps as mistake might result in inability of AGENTs connect to both old and new server, and thus requiring manual repair.

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 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

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 that could be blocking requests? I can see that non-standard ESET repository url is used, the one that directs requests to only ESET datacenters and not public CDN providers. Also please make sure HTTP proxy is properly configured and running, in case it is used.

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.

Just to be sure, please check that you have actually enabled collection of non-ESET applications in configuration policy for ESET Management Agents -> it is not enabled by default.

I would recommend to follow troubleshooting guide (https://help.eset.com/protect_admin/80/en-US/mdm_troubleshooting.html?fs_agent_connection_troubleshooting.html), which will help you how to enable full-verbosity logging even on devices which are not managed yet, and thus increase chance it will be possible to find out what could be wrong. In this case, error is network related, which might be caused by various network related components (firewalls, etc..) or there might be even problem with DNS resolving of hostname used for connection to EP.

Thanks for clarification. Now I can confirm that certificates used by AGENTs to communicate with EP are not related in any way with certificate used by console, and visible in web browser -> you can replace it anytime without impacting management of devices. When replacing console certificate, you just have to make sure Apache Tomcat configuration is correct, otherwise you might loose access to console...

Could you please provide more details of what would you like to report? Or just older data? Asking because there is no hidden filter, but the data itself is collected and processed in a way that only 30 days are available for reporting mechanism (most probably due to performance/amount of data), even that is possible to access older data directly in console, but not in aggregated form.

RDSensor used passive detection, i.e. it is not opening SSH connection to other devices. ESET PROTECT can indeed initiate SSH connections as part of "Remote agent deployment task" (documentation). I would recommend to check console for execution records for this task type, and if it will be present, I would check whether it was not scheduled for execution in a way it would trigger detections you mentioned. It is not possible this task would run without user's consent or selection of "targets"