MartinK

Hello, this is problem we had in older versions (you are using ERA 6.1?): No such node (result.strIssuer) AGENTs configuration (it's certificate) is corrupted due to invalid configuration policy on SERVER (current version have validators for this problem). Please check all configuration policies for product ESET Remote Administrator Agent applied to affected AGENTs, and find out those that are "apply-ing" Connection->Certificate value. Make sure all of them are applying working certificate with proper password. Once policies are fixed, you will have to repair also AGENTs, but this time they should not break after first connection to SERVER.

There may be more detailed error message in SERVER trace.log. Please also provide SERVER and Webconsole version (from About page), so that we are sure correct version were available to download ... EDIT: we made some internal testing and were able to reproduce the same problem with old Webconsole (6.2) connecting to 6.3 SERVER. In case this is tour case, please provide details of your upgrade steps - there may be problem with our download servers or repository.

Could you please verify all your components were upgraded successfully? Especially version of ERA Server and Webconsole must match. Similar problems can also happen due to browser caching - please try to logout from Webconsole and reload login page (Ctrl+F5) in case you have not done that already.

Their certificates don't have to share CA certificates, but in order to communicate, each of them must have CA certificate of remote peer. Your mentioned scenario will not work, because ERAS-B AGENTs will be missing ERAS-A CA certificate. You can fix it by importing all CA certificates to both ERAS-A and ERAS-B (each of them will have at least two CA certificates) ... once all AGENTS will connect to their respective ERA server, they will have both CA certificates and from that moment they will be able to connect to both servers and both servers will be able to accept them. It will work, but make sure you import CA certificate of this shared SERVER certificate into both ERA servers before and wait until all AGENTs connect. If you miss this, AGENTS won't be able to connect, not even to primary ERA server because once they connect to secondary server, they will drop CA certificates they had previously and will synchronize state with secondary server. There will be no notification on AGENT, but you will see warnings 30 days before this happens in ERAS console. Once expired, AGENT will be still trying to connect as nothing changed. Client computers won't be removed directly, but they will stop connecting, therefore server task "Delete Not Connecting Computers" will eventually remove them if configured to do so.

ERA all-in-one is supposed to simplify installation process and therefore set of parameter is reduced to minimum. Most of the storage requirements will be taken by SQL Express database, which can be installed manually on different drive as described here - database installation and configuration is described here hxxp://support.eset.com/kb3671/?viewlocale=en_US. Once database is configured you can proceed with installation using all-in-one installer (to C:/) or install each component manually which will enable you to install all components to non-standard drives.

Hello, we have seen similar problems when MariaDB database has been used instead of "original" MySQL - is this your case? If you are using supported database type, could you check SERVER trace.log for errors that could indicate possible problems?

Thanks, relevant output is: 2016-01-18 12:05:59 Information: CDatabaseModule [Thread c9c]: Reports time: total: 56646ms from mem: 0ms to db: 16ms from db: 14572ms guard: 0ms sql exec: 41948ms 2016-01-18 12:05:59 Information: CDatabaseModule [Thread c9c]: Reports rows: read: 137967 to db: 13 from db: 137967 where we can see that it took more then 56 seconds to fetch data (137967 rows) from database. Could you please try to increase RAM? We are recommending at least 4GB for this type of all-in-one installation scenarios - especially database server should benefit from it.

We have experienced this when upgrading from previous versions (that is reason it is mentioned in official release notes as unsupported), but it seems there are also other scenarios that does not work correctly. Problem is that for some reason installation cannot be performed in one step and it requires restart before it is finalized (reason may be previous system updates performed without restart). Regardless of reason, this two-step installation process is unfortunately unsupported by ERA and only possibility is to install manually. You can download ESET File Security installer directly from eset.com page and install it. AGENT will automatically recognize new installation.

Please provide some details about your configuration, especially database type, database version, memory and CPU. Also it would help us if you could: enable "debug" verbosity of trace log in SERVER configuration try to generate problematic report and wait until it fails revert trace log verbosity in SERVER configuration and search SERVER trace.log for something like this: 2016-01-18 08:53:04 Information: CReportsModule [Thread 7f79f7fff700]: 2 MessageProcessorThread starting report generation 327 2016-01-18 08:53:04 Information: CDatabaseModule [Thread 7f79f7fff700]: Reports: ID: 137 name: Fetchwebcontrolagregated_eventReportMapper 2016-01-18 08:53:04 Information: CDatabaseModule [Thread 7f79f7fff700]: Reports: CALL usp_load_server_info(); 2016-01-18 08:53:04 Information: CDatabaseModule [Thread 7f79f7fff700]: Reports: CALL usp_create_table_computers_ids(); 2016-01-18 08:53:04 Information: CDatabaseModule [Thread 7f79f7fff700]: Reports SQL: SELECT TL00120.SourceUuid,TL00120.Severity,TL00120.Occurred,TL00120.Account,TL00120.Url,TL00120.MatchingUrl,TL00120.CategoryId,TL00120.ActionId,TL00120.Count,TL00120.CSN,TL00120.sequence_no FROM tbl_computers_ids AS CID JOIN tbl_computers AS C ON C.computer_id=CID.id JOIN tbl_log_webcontrolagregated_event AS TL00120 ON TL00120.SourceUuid_id=C.computer_id WHERE (C.removed = 0) ORDER BY TL00120.Occurred DESC 2016-01-18 08:53:04 Information: CDatabaseModule [Thread 7f79f7fff700]: Reports time: total: 3ms (cpu) total: 9ms from mem: 0ms to db: 0ms from db: 0ms guard: 0ms sql exec: 0ms 2016-01-18 08:53:04 Information: CDatabaseModule [Thread 7f79f7fff700]: Reports rows: read: 0 to db: 3 from db: 0 2016-01-18 08:53:04 Information: CDatabaseModule [Thread 7f79f7fff700]: Reports: protobuf size: 0.00 MB 2016-01-18 08:53:04 Information: CReportsModule [Thread 7f79f7fff700]: 2 MessageProcessorThread ended report generation 327 2016-01-18 08:53:04 Information: CReportsModule [Thread 7f79f7fff700]: 2 CReportGenerator::MessageProcessorThread(): report localization takes 0 ms 2016-01-18 08:53:04 Information: CReportsModule [Thread 7f79f7fff700]: 2 CReportGenerator::MessageProcessorThread(): report size (before,after) localization: (0.00,0.00) MB 2016-01-18 08:53:04 Information: CReportsModule [Thread 7f79f7fff700]: 2 CReportGenerator::MessageProcessorThread(): report sorting takes 0 ms 2016-01-18 08:53:04 Information: CReportsModule [Thread 7f79f7fff700]: GenerateReport copying ended 327 time: 0 ms It may help us to locate source of your performance problem.

Does it take some time (60 or more seconds) before it fails? If this is the case, it is most probably performance problem with too many data. Please try to add some filter to your report template that will decrease number of processed data -> not sure if available in your version, but check other pre-defined report templates for "Range Report" in theirs filter section for report data paging. In case it fails immediately after execution, please provide full error message from SERVER trace.log.

Any chance you had older version of ESET File Security already installed on affected servers?

I hope it is activated in case AGENT managing MDC is not reporting any issues. Are they any other issues except error output in trace.log you posted earlier? Regarding MDC version information - it is yet another issue in ESET repository. Version 6.2.176.0 is the latest official MDC release. Please ignore these version check report, it is caused by undergoing preparations for new release.

All "applied" settings are automatically locked and there is no way how to disable this functionality. Lock will be removed once policy is no longer assigned to this specific client (remove policy, or remove association between policy and client).

Parameter /i means "Installs or configures a product." as described here: https://technet.microsoft.com/en-us/library/cc759262%28v=ws.10%29.aspx Current version does not support password protection, but it will be available very soon (6.3). Current AGENT version is protected only by installed endpoint -> and this protection is not suitable against users with administrator privileges.

In case it works as you expected, there is no reason to change . I just realized my proposal was not complete replacement for your scenario and it would also need some work ...

Just a note: for your scenario would be most suitable deploying OVAs as "ESET Remote Administrator Proxy" -> you would have the same caching capabilities as now and in addition also ERA Proxy server that can "mediate" communication between ERA Agents and ERA Server (= communication through port 2222) as described here: hxxp://support.eset.com/kb3639/?locale=en_US

Thanks for finding out yet another bug, this time in ESET packages repository -> wrong package type - not suitable for ERA is available instead of plain RPM package. Until this issue is resolved (may take more than 24 hours), there is no easy way how to upgrade/install ESLC using ERA except some kind of shell trickery in "Run Command" client task. I would recommend to download package from ESET website and install it manually - it should not require any additional parameters. In case you are using locked ESLC appliance, I would recommend to wait until supported package type is available.

Happy to hear you were successful. ERA (and MDM) is currently not able to use socket files when connection to database (we are using TCP connections) but in appliance, MySQL driver misinterprets default database hostname "localhost" and tries to use local socket file instead of TCP sockets. You can work-around this explicitly specifying database server hostname to "--db-hostname=127.0.0.1" as we are doing. Regarding update failure .. is MDC activated? Could you try to re-activate it?

Tried the server assisted installation, but the install script still requested for the database connection If useful, this is how 6.1.414 was installed: ./MDMCore-Linux-x86_64.sh --webconsole-password="$secret" --db-type="MySQL Server" --db-driver="MySQL ODBC 5.3 ANSI Driver" --hostname=*** --https-cert-path=mycert.pfx --db-admin-username=root --db-admin-password="$secret" --db-user-password="$secret2" --db-hostname=localhost --db-port=3306 Would it work to re-run the new installer with the same params? On the other hand, all these params are stored in the config file... I think "server assisted" scenario won't work for repair or upgrade, only for new installations. But in case you have original DB-related parameters, simply add them to command I thought would work ... in worst case you will have to add all parameters that are required for clean "offline" installation of MDC 6.2 as is described in referenced documentation.

Hoped it is not this case ... you are right, there is no interactive setup and I cannot find any guide for manual upgrade on appliance. Technically it is almost the same as installing new version, except that you can skip certain command line parameters (their value will be loaded from current installation). I have currently no way how to test it (please create backup or snapshot before proceeding), but I would try to install new version using parameters: ./MDMCore-Linux-x86_64.sh --skip-license --hostname=<ERA SERVER HOSTNAME> --port=2222 --cert-path=Proxy.pfx --cert-auth-path=CA.der where Proxy.pfx is certificate created in ERA for Proxy product (this is different than for previous MDC versions). Specific arguments are described in documentation: hxxp://help.eset.com/era_install/62/en-US/index.html?mobile_connector_installation_linux.htm .

Merging of computer is currently handled by "Static group synchronization task", but there are two main conditions for computers to be merged: All computers must have exactly the same name (FQDN) At most one of computers with the same name can be "managed" so there i no way how to "merge" multiple computers with their data, only remove "unused" entries in static groups. In case your duplicate computer conform to the second condition, you should not loose anything except entry in static groups (=name and description of this object). It is because AGENT-less computers had never executed any task, never received any configuration and never sent any data to this SERVER.

Could you be more specific about step 1.1? Have you tried to install AGENT manually without mst? In case you used "Remote installation task", have you provided credentials for local administrator account? If you want we can take a look at complete installation log, because actual installation failure is not visible in attached part - you can PM it to Marcos or me. All ERA installation and deployment tasks require synchronization with ESET packages repository prior to actual installation. Synchronization means downloading multiple metadata files from hxxp://repository.eset.com/v1/. Could you please verify you have access to this host? Are you using HTTP proxy that could possibly block connection?

Yes, the simplest way how to upgrade to MDC 6.2 (from 6.0 or 6.1) is to manually run MSI installer in interactive mode. Reason that it is not possible upgrade using "Upgrade infrastructure" task is that MDC 6.2 introduced "breaking" changes in configuration and new parameters (new certificate type) are required and therefore silent installation is not possible. Future releases are expected to support silent upgrade (if nothing goes wrong, upgrade from 6.2 to 6.3 will be possible using mentioned task)

It is very short part of trace.log to make any conclusions, but from what I can see everything is as it should be except that connection to you SERVER was not opened in time (there is 5 minutes timeout). There are many possibilities for this: network configuration problem (I have seen similar behavior in case port forwarding configuration for virtual network was not configured properly, and also in cases target machines was not listening at requested port) DNS name resolution problem (DNS response for hostname of your server takes too much time): if possible, try to repair affected AGENT and use IP address instead of hostname when specifying ERA server. Also please verify resolved IP address is correct. ERA server may not be accepting new connections for some reason: please verify that other AGENTs are still connecting (last connection time seen in Webconsole). There may also be related errors in ERA SERVER trace.log. firewall or other security tools may be blocking connection: please disable software that could be interfering with AGENT connections (even ESET Antivirus if installed also). You may also use tools like Wireshark to analyze whether connection request is received to ERA SERVER or it is lost somewhere between.

Seems task are not being executed, because AGENTs installed on affected systems are not able to connect to ERA server. Could you please verify that ERA server is accessible from AGENT computers and there is no firewall blocking connection? I would try to open telnet/ssh connection from those system so ERA Server on port 2222 and check whether connection is opened or not (do not except any data in case it is opened).