MartinK

Installer thinks that this application is already installed and therefore it tries to perform upgrade - which obviously fails because there are not files: FindRelatedProducts: Found application: {A0E7525A-7F3D-407B-80DD-E992D2745203} There are two possibilities this to happen: There was previously installed ERA and windows registries were not properly cleared during it's uninstallation There is another application installed with the same GUID (very low probability) Please try to search windows registry for A0E7525A-7F3D-407B-80DD-E992D2745203, A0E7525A7F3D407B80DDE992D2745203, A5257E0A-D3F7-B704-08DD-9E292D472530, A5257E0AD3F7B70408DD9E292D472530 and possibly also for key value "ESET Remote Administrator Agent". In case you won't be able to find mentioned record, tools like procmon may be helpful to find out where does msiexec finds this GUID.

Could you please provide more information? Especially full installation log from MSIEXEC may be most usable for use. Error from screenshot indicates that AGENT's database cannot be created - could you check that directory c:\ProgramData\ESET\RemoteAdministrator\Agent\EraAgentApplicationData\Data\ does not exist before you start installation? Is there any chance there was older version of AGENT already installed?

There is currently no way how to disable reverse-DNS resolving during initial computer creation in Lost&Found group - it is because in moment of creation, there is not yet information about real hostname. I would suggest to modify configuration of pre-installed "Computer rename task" so that it runs more often in case default 60 minutes interval is not sufficient. We are currently analyzing possible improvements for this issue, so there is chance that it will change in next releases. I would also remind you that hostname provided by AGENT is less reliable and may be spoofed (changed by local admin as he wishes) - therefore I suggest to be careful with renaming task, especially on computer outside of Lost&Found group. You are right, NAT may cause confusion and you will have multiple computers with the same name (IP address of NAT) until renaming task is executed. MariaDB is unfortunately not supported - there are differences in DB that causes ERA to silently fail during specific operations which leads to unusable product. Therefore we added in 6.3 installer that will block installation on MariaDB database.

yes, first I try to install using a custom repository but failed, then i try to install using the repository eset but failed again So error I found in proxy logs are caused by permissions configuration of Apache HTTP Proxy - it is not configured to server custom files, only cached ones. In case you want to use our proxy as HTTP share, you should change configuration as described here: https://wiki.apache.org/httpd/ClientDeniedByServerConfiguration When you used ESET repository, error was different?

Isn't this enough to rename computer in ERAv6? hxxp://support.eset.com/kb3717/?locale=en_US Yes, you can of course rename computer manually and results are the same.

hi: try to run the task manually but I can not see whether the task is running. and the computer name is still ip address. I test delete/install the agent many times. I remember at some point I could see the hostname as pc name. but now I think my era server is broken. I will try to reinstall it. I am using rhel 7.2 and mariadb. I see some forum posts indicate that era server may have problem with mariadb. if I fall back to mysql, what version would Eset recommend? 5.5 or 5.6 or 5.7? thanks a lot for confirm. You did not mention ERA version, but In case computer is name IP address, it means there is something wrong with reverse DNS resolving. Mentioned renaming task will rename computer to name it is reporting, therefore this client must be successfully connecting and reporting required values. In your case this is probably not working due to MariaDB (you can check client details whether you see anything in section "Device identifiers"). Recommended database in this case would be MySQL 5.6 (current versions of MySQL 5.7 has bugs that are affecting certain ERA functionality and may cause problems).

There are multiple errors like this: [access_compat:error] [pid 3080:tid 844] [client 192.168.0.160:50662] AH01797: client denied by server configuration: proxy:hxxp://192.168.0.180:3128/ees_nt64_esl.msi which indicates that HTTP Proxy is not configured to enable download file from this path - but I am confused by path it is showing .. how actually you are using software installation task? Are you using repository package to install, or you are trying to install package from specific URL?

Is it possible to provide us (PM) a wireshark/tcpdump with captured HTTP traffic during task execution? We have seen similar errors in multiple situations, but all of them were random. Technically it means, that HTTP server (in your case proxy in case this file is cached) did not send whole installation file or connection was closed during download of installation file. Have you checked logs of your HTTP Proxy whether there are no suspicious entries?

Please check KB3675 for parameters descriptions. There may be multiple alternatives, so feel free to ask if something does not work as you expected.

It is a feature (part of self-defense) and I do not expect it to be removed. Could you be more specific about situations that required AGENT to be restarted? It should have no impact on most AGENT's operations, except maybe "fixing" potential problems.

Unfortunately there is currently no way how to cancel tasks. Could you be more specific about task types that gets stuck?

Agent installed side-by-side SERVER will provide specific OS information for reports showing ERA infrastructure. In current release, omitting AGENT installation should not affect may functionality of ERA.. But we do not recommend it because it may change in the future. Are there any specific reasons for not installing AGENT in your environment?

Could you please specify you SERVER configuration - platform, database type? Does restarting ERA service makes any difference? Have you been recently doing any ERA database or machine reverts? When you open client details view, are there any missing fields? Does this happens for all clients or only specific set? Affected clients are standard AGENT installation or they are virtual machines protected by EVS/VirtualAgentHost? Could you check SERVER's trace.log for errors - especially database related errors? Problem is that for some reason there is no "Last connected" information for these clients and therefore they are marked as unmanaged.

It is running as service under "Local System account" by default - but it may be manually changed Could you clarify and add information regarding that manual change? That could be the solution if I can change the user to some other network user. Change is possible by manual change in "Services", but it is not documented - therefore I would recommend it only as a last resort because there may be issues with permissions required by ERAAgent itself.

Please check steps described in related KB article

It is running as service under "Local System account" by default - but it may be manually changed No, it is currently not possible. Unfortunately I have not encountered such script. Maybe you could inspire in generated live installer. It is technically bat file which drops another script and executes it under administrator privileges - but I am not sure it will be usable in this task.

Unfortunately script is executed "asynchronously" and therefore AGENT is not collecting its output. In case you see "Task successful" in ERA it means script started, but tells you nothing about it's content results. We are aware it is not ideal but I would suggest to use some kind of "logging" in your task - at least writing to some file. Have you tried to execute mentioned bat file manually? Even Windows itself has some limitations when network shares are involved and it has problem with mixing local and network locations.

On Windows, content of command line is written into regular bat file and executed - it can even be a multi-line set of commands. In case you are not sure, I would suggest to create testing .bat on target machine and once it works, you may try to use it from ERA. Beware of multiple limitations as file will be executed with AGENT's permissions (Local System?) and I am not sure where from - so do not rely on default working directory. Please avoid usage of UTF8 paths or parameters, as it may cause problems on older Windows machines.

I guess you used AD synchronization task for creation of those "unmanaged" computers. Now you have to re-run AD synchronization so that newly created computers (they should have initially appeared in Lost&Found group) are moved to proper place. Alternatively you could move connecting computer to proper group and remove those not-connecting duplicates, as this is what will do AD synchronization task.

Your network configuration seems absolutely fine. Have you checked all groups whether there is not computer you are looking for? It may be listed with different name than you expected...also AD synchronization task could possibly move it to different group based on name. also make sure there is not any non-standard filter set for main clients view (maybe based on product type that is not installed in these newly added AGENT's). Could you also search SERVER's trace.log for errors? To be sure, try to restart Apache Tomcat that is hosting ERA Webconsole - to be sure there is nothing cached.

If I understand it correctly, you synchronized computers with AD and used GPO deployment (ERA live installer). In that case, once AGENT connects first time after installation, new computer should be created in Lost&Found group. Could you check it whether there is such computer that is connecting? In case you found it and it has exactly the same name, another execution of properly configured AD synchronization task should "merge" these computers.

Error 2016-03-08 21:00:53 Error: NetworkModule [Thread 7f450d7fb700]: Cannot initialize protocol plug-in. Expected kernelType Console means that there is something connecting to Webconsole port of ERA (default 2223) but it is not Webconsole ... maybe AGENT are missconfigured to use port 2223 for their connection? Or maybe you have been changing SERVER's listening ports configuration? Could you please check AGENT trace.log or status.html for possible errors as seen by other end of connection?

As MichalJ wrote, it is not officially supported, but AGENT should be able to run on Ubuntu since version 8.04 in case requirements are met: installed openssl (libcrypto) library libc6 version 2.3.6 and newer linux kernel 2.4.17 and newer In case you encounter any problems, please provide details.

How you installed those SERVERs? Cluster installation or they are completely different installation now configured to connect to the same database? How do you expect it to work? Instance UUID is stored in /etc/opt/eset/RemoteAdministrator/Server/config.cfg and in case both SERVERs are sharing one database, they have to share also UUID - and it must be the same UUID as in in database. Please ignore UUID that you found in sql scripts - it is only default value replaced during installation process.

In case you are using MySQL database, does restarting SERVER makes any difference? In case yes, it will be most probably the same problem as described in another topic