msizec

Oh yes ... that's it ... didn't see it. After some testing it seems to work as I want ... Thank you MartinK

The former is my case yes. And I was planning to test the mirroring functionity using a local path tomorrow. The fact is that when I have my proxy server set, updates are made from the proxy (using netstat I can see the server IP). But they do not fail so I guess they are served by the proxy server. And when I deactivate the proxy server setting, netstat shows me that the PC is connecting to the mirror server. I guess we'll have to use mirroring from local path

Hello ! Here again ! Ive done some testing ... And I can tell you that when the option "Tools > Proxy Server > Use a proxy server" is activated, and you have also set the option "Updates > General > Update Server > Update Server " to a local mirror, when you do an update, ESET requests (for licensing etc AND UPDATES) pass through the proxy and not through the mirror. I've been told that hte mirroring would still be functionnal when using a proxy server ... Is all of this normal ? My previous thread : https://forum.eset.com/topic/8391-mirroring-and-proxy/

MantinK, these kind of sql errors happen only at midnight. But 20hours after the server's update, the queue I mentionned in the top post is still empty.

I did search through the trace.log of ERA. There are lines of errors but I don't know what I'm looking for. Theres a bunch of duplicate errors. But the fact is I just updated ERA server and the queue seems to be almost empty now

These are the only errors I can find (im using SQLSERVER) in a trace file But there is a bunch of it (since 02-02-16) so I don't think thats the culprit : 2016-06-06 00:00:12.46 spid51 Table 'tbl_log_rdsensor_newcomputers_status' will not be available during reorganizing index 'tbl_uk'. This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked. 2016-06-06 00:00:12.47 spid51 Table 'tbl_log_functionality_products_status' will not be available during reorganizing index 'PK_tbl_log_functionality_products_status'. This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked. 2016-06-06 00:00:12.47 spid51 Table 'tbl_log_activethreats_status' will not be available during reorganizing index 'PK_tbl_log_activethreats_status'. This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked. 2016-06-06 00:00:12.48 spid51 Table 'tbl_policies' will not be available during reorganizing index 'PK_tbl_policies_policy_id'. This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked. 2016-06-06 00:00:12.48 spid51 Table 'tbl_static_object_changes' will not be available during reorganizing index 'tbl_static_object_changes$transaction_id'. This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked. 2016-06-06 00:00:12.48 spid51 Table 'tbl_log_eesvirusdb_status' will not be available during reorganizing index 'PK_tbl_log_eesvirusdb_status'. This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked. 2016-06-06 00:00:12.48 spid51 Table 'tbl_log_exportedconfiguration_event' will not be available during reorganizing index 'PK_tbl_log_exportedconfiguration_event'. This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked. 2016-06-06 00:00:12.49 spid51 Table 'tbl_log_scan_event' will not be available during reorganizing index 'sui'. This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked. 2016-06-06 00:00:12.49 spid51 Table 'tbl_static_object_changes' will not be available during reorganizing index 'tbl_static_object_changes$object_uuid'. This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked. 2016-06-06 00:00:12.49 spid51 Table 'tbl_log_apps_currentversion_status' will not be available during reorganizing index 'PK_tbl_log_apps_currentversion_status'. This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked. 2016-06-06 00:00:12.49 spid51 Table 'tbl_automation_server_tasks' will not be available during reorganizing index 'PK_tbl_automation_server_tasks_task_uuid'. This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked. 2016-06-06 00:00:12.50 spid51 Table 'tbl_dashboards' will not be available during reorganizing index 'PK_tbl_dashboards_dashboards_id'. This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked. 2016-06-06 00:00:12.50 spid51 Table 'tbl_log_security_product_status_snapshot' will not be available during reorganizing index 'sui'. This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked. 2016-06-06 00:00:12.50 spid51 Table 'tbl_log_threat_event' will not be available during reorganizing index 'tbl_uk'. This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked. 2016-06-06 00:00:12.50 spid51 Table 'tbl_log_threat_event' will not be available during reorganizing index 'sui'. This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked. 2016-06-06 00:00:12.51 spid51 Table 'tbl_static_object_ids' will not be available during reorganizing index 'PK_tbl_static_object_ids_object_id'. This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked. 2016-06-06 00:00:12.52 spid51 Table 'tbl_log_scan_event' will not be available during reorganizing index 'tbl_uk'. This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked. 2016-06-06 00:00:12.52 spid51 Table 'tbl_log_quarantine_content_status' will not be available during reorganizing index 'PK_tbl_log_quarantine_content_status'. This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked. 2016-06-06 00:00:12.53 spid51 Table 'tbl_log_performance_server_event' will not be available during reorganizing index 'idx_gIndex1'. This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked. 2016-06-06 00:00:12.57 spid51 Table 'tbl_log_scan_event' will not be available during reorganizing index 'idx_gIndex1'. This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked. 2016-06-06 00:00:12.58 spid51 Table 'tbl_log_task_server_status' will not be available during reorganizing index 'sui'. This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked. 2016-06-06 00:00:12.59 spid51 Table 'tbl_log_repository_software_status' will not be available during reorganizing index 'PK_tbl_log_repository_software_status'. This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked. 2016-06-06 00:00:12.62 spid51 Table 'tbl_log_task_detail_agentdeployment_status' will not be available during reorganizing index 'sui'. This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked. 2016-06-06 00:00:12.63 spid51 Table 'tbl_log_functionality_problemsdetails_status' will not be available during reorganizing index 'PK_tbl_log_functionality_problemsdetails_status'. This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked. 2016-06-06 00:00:12.63 spid51 Table 'tbl_log_apps_installed_status' will not be available during reorganizing index 'PK_tbl_log_apps_installed_status'. This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked.

It keeps growing ...

hello, Theres a report that semmes to indicate that something is going wrong in ERA. In french, its called : "File d'attente des journaux du serveur". Its the 5th report in the "server performance" group. Can you give me a hint on what's need to be done/check ?

My SMTP configuration is ok. When I click the test button, it shows me this error message : Le message de test n'a pas été correctement envoyé. Arguments insuffisants pour sk.eset.era.g2webconsole.server.modules.config.ConfigEngineModuleImpl.testSmtpSettings(ConfigEngineModuleImpl.java:70 Then if I enter the same password, and do the test again, it works. If I save the parameters, and right away display them again and do a test, I fails.

Seems easy you're right ! Thx !!!

Yeah it is what I will recommend to my IT boss, but if I check "Autoselect" it will choose the correct ESET's server, and not my ERA server ? Or will it choose my ERA server and don't do delayed update (because my server is on regular updates)

I did not find a way to reactivate via ERA a computer that I deactivated manually via ESET security gui Wondering too how to do this

So Autoselect will choose the correct ESET's server, and not my ERA server, correct ?

The fact is that the computer with IP defined as local mirror for my computers, doesn't have the mirroring parameters on (yes pretty ugly, someone got fired recently). But computers are still updating (which is good but I don't know why )

Ok. So I can have delayed update using mirroring if I set my mirror computer to "delayed update" with autoselect and then I set my computers to get updates from the mirror ?