MartinK

You could specify hostname or IP address to which newly installed AGENTs will be connecting in live installers wizard, specifically in optional field called Server hostname. This will work only in case your PROXY is listening on the same port as SERVER and PROXY certificate is signed with the same CA certificate as SERVER certificate currently being used (both are default scenario).

MySQL query is even simpler: call usp_replication_realm_uuid_set(UUID());

Please attach content of /etc/odbcinst.ini to be sure it is correctly configured.

Thanks for fast reply. We have one last question in our external IP survey: How would you use this external IP if available? Only visual confirmation in Webconsole? or you would also expect dynamic groups and client task (task executed on remote machine) to work based on this IP address? switching configuration based on IP address client is using? We are asking because this feature was not removed intentionally, but it is not available due to architecture changes since previous ERA generations. It's integration into ERA6 may come with limitations in usability in comparison with currently available data collected on client computers.

To be honest with you, I don't see why such a large number of features/information was removed from the latest version of ESET. It's like buying a car with a new fancy GPS, but then removing the headlights allowing you to only drive during the day. Hello, could you be more specific about your use-case - how should ERA fetch external IP of device behind NAT? Currently we are collecting all IP addresses that are reported on client (AGENT) machine. We have discussed as alternative providing also IP address that AGENT connection comes from when connecting to SERVER - but this is useless in case devices are behind NAT -> all devices will the same IP address.

Please check my post https://forum.eset.com/topic/7249-simultaneous-connection-count/#entry39255 whether it helps. It will require simple modification of ODBC driver configuration.

Migration of DB server is documented here: hxxp://help.eset.com/era_install/63/en-US/db_migration_sql.htm

When it stops working, please check /var/log/eset/RemoteAdministrator/Server/trace.log for Error entries. Those invalid average number should not be related to this problem. Also we have seen similar behavior in case unsupported MariaDB was used instead of MySQL database - what database/version are you using? Please provide content of /etc/odbcinst.ini or at least check whether multi-threading is enabled for you MySQL driver -> it is parameter Threading=0 as described in ERA documentation: hxxp://help.eset.com/era_install/63/en-US/index.html?odbc_configuration.htm

Thanks for reporting. Both issues should be fixed in next release. In the meantime, you can try workaround for the first issue: stop SERVER service, replace file C:\ProgramData\ESET\RemoteAdministrator\Server\EraServerApplicationData\Localization\LangData.dat with the file from attached archive and start SERVER service. Be advised that it is not tested = please create backup of original file and restore it once you encounter any problem with localization. Also not that this file is suitable only for 6.3.12.0 release and will be replaced by upgrade or repair of SERVER installation. LangData.zip

I backup and restore DB from another to the new one. Then I drop 'era_user' account before installing ERA 6.3. But I always get failed message. I also try to keep 'era_user' account, then install ERA 6.3. But I got the same error message. So could you please tell me what is the right procedure if I'd like to migrate DB from another server to new one? Thank you. We have been trying to find at least workaround, but unfortunately we were not successful -> all-in-one installer was expected to be used for clean installations and mentioned scenario was not considered (nor tested), therefore newly introduced changes broke it. Currently only migration of DB to new server, but without re-installing ERA Server is supported, as described in documentation: hxxp://help.eset.com/era_install/63/en-US/db_migration_sql.htm. You could possibly install ERA Server and other components manually. Could you please provide more details or reason why are you migrating whole ERA installation to different server? Could you please

Please ignore those "enormous" numbers. Seems there are caused by broken arithmetic computations, and we will be investigating it. In case last connection time is still not working, could you try to restart ERA SERVER service and check (after few minutes) whether it helped? Also please check whether currently shown times are not "in the future", because current logic is not showing last connection time, but latest time of previous connections (= check whether local time on SERVER is correct).

There seems to be problem with authentication into cloned database: [Microsoft][ODBC SQL Server Driver][SQL Server]Login failed for user 'era_user' have you migrated also DB user era_user? There has been some changes in this phase of installation (reducing required permissions) and it seems user is no longer automatically created in case you are installing ERA using existing database.

Import of policies in .xml format is not supported. I would suggest you to export EES from configuration from ERA (Client details -> Configuration -> Request Configuration button), and once configuration is received, you can pen it and use "Convert to policy" button to create policy.

Is there any chance you have not restarted tomcat when you were upgrading to 6.3 for the first time? Or did you use "Components Upgrade" task? We are now almost confident you were fore some reason using old Webconsole (maybe only some caching problem in tomcat). Your current problems are expected after reverting database and it should take no more than 24 hours to fully recover. AGENTs currently "think" they have already sent data to SERVER and they do no know is has been reverted, but they will re-send data in upcoming hours. You can speed-it up by changing SERVER realm, which is currently undocumented way how to force re-synchronization in ERA infrastructure. Unfortunately only possible way is to run next SQL commands directly over ERA database: declare @new_uuid char(36); SET @new_uuid = LOWER(NEWID()); exec dbo.usp_replication_realm_uuid_set @new_uuid; and restart SERVER. We strongly recommend to run it in your case, because you have reverted SERVER not only back-in-time, but also to older version from AGENTs point of view.

Yes, you have to find and fix configuration policy with invalid certificate. ERA 6.2 has improved validation that should notify you about problem once you try to edit problematic policy. As mentioned previously, problem is either empty data for certificate or invalid password -> both cases should be validated.

In this case "broken" configuration policy will be most probably older, created before upgrade to 6.2. Also you mentioned it starts failing after restart -> maybe it is policy attached to some dynamic group.

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.