antoineL

There seems to be a catch-22 problem. My server runs Server version 9.1.0.1295 and Agent version 9.1.0.1295. I am seeing everywhere (dashboard, machine details etc) that the agent is out-of-date, and I understand why. However, the automatic update task does not seem to apply to that machine; and when I select that particular machine and press Update ESET Products, I am told: "No ESET products that can be updated automatically have been found."

ERA Protect server 9.0.1144 on Windows 2016 with SQL server 2014 Express 12.0.6433, ERA.war 9.0.138 on Tomcat 9.0.63/Microsoft JDK 17.0.3, all on the same server. This setup works flawlessly for several months; but today I got strange failures. When looking at many reports (not all), through dashboard or directly under Reports/, I got an alert "Failed to load data; 500 The call failed on the server: see server log for details." With the dashboard, I got as many alerts as there are report widgets, so I guess it is report-related. I do not know which "server log" I should look at; I searched ERAserver, Tomcat, SQLserver and did not get anything which might correlate the problem. However, I got another error (which is probably related) when I try to edit the report definition (slightly edited at the URL): *version : 9.0.138.0* *locale : en_US* *user.agent : Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/101.0.4951.67 Safari/537.36 (safari)* *document : https://XXX[edited]XXX/era/webconsole/184D1BF85E74D609DBF00589DCF2E826.cache.html* *url: https://XXX[edited]XXX/era/webconsole/#id=REPORTS:id=EDIT_REPORT_TEMPLATE;rtu=977b9fb8-fad7-4584-8b37-c491675d6613;p=6* *error: * An uncaught exception has occurred! (com.google.gwt.core.client.JavaScriptException: (TypeError) : Cannot read properties of null (reading &#39;f&#39;)) @Unknown.f8n(Unknown Source:80)@ @Unknown._zg(Unknown Source:1211)@ @Unknown.PAg(Unknown Source:1093)@ @Unknown.G4n(Unknown Source:137)@ @Unknown.$zg(Unknown Source:1084)@ @Unknown.Szg(Unknown Source:857)@ @Unknown.tAg(Unknown Source:1971)@ @Unknown.bBg(Unknown Source:1857)@ @Unknown.Gzg(Unknown Source:747)@ @Unknown.uzg(Unknown Source:1849)@ @Unknown._el(Unknown Source:293)@ @Unknown.mSe(Unknown Source:564)@ @Unknown.pSe(Unknown Source:541)@ @Unknown.ARe(Unknown Source:343)@ @Unknown.dSe(Unknown Source:357)@ @Unknown.cSe(Unknown Source:355)@ @Unknown.lSe(Unknown Source:382)@ @Unknown.KSj(Unknown Source:831)@ @Unknown.In(Unknown Source:582)@ @Unknown.Nn(Unknown Source:276)@ @Unknown.jo(Unknown Source:309)@ @Unknown.mo(Unknown Source:361)@ @Unknown.anonymous(Unknown Source:78)@ @Unknown.Ao(Unknown Source:173)@ @Unknown.Zo(Unknown Source:60)@ @Unknown.anonymous(Unknown Source:85)@ @Unknown.jo(Unknown Source:309)@ @Unknown.mo(Unknown Source:361)@ @Unknown.anonymous(Unknown Source:78)@ Javascript cause: <br/>@TypeError: Cannot read properties of null (reading &#39;f&#39;)@ By the way, that one is with Chrome; but I got the same failure with almost the same message on Firefox 91.9.1; just Firefox adds a TypeError exception is raised since "this.H.c.G is null"

Thanks to confirm what I was thinking while writing yesterday. It very much looks like I was side-tracked by the fact the "re-deployment" task is listed under Server tasks, while the "standard upgrade" is under Client tasks. I know client deployment is almost exactly at the midpoint between the two categories, but the fact the two tasks are classified differently does not help at all. About revocation, I am going to take your answer as meaning that revocation is the way to go when one wants to get rid of an expired certificate, even if the purpose is not to technically invalidate it (since an expired certificate is already invalid.) Perhaps you could ask to improve the documentation this about? (By the way, while the French version says the same as the English one, the Spanish one uses another word, "cancelled" instead of "invalidated", which I find a bit less misleading. Even if I'll prefer to read "Removed".)

Thanks for rephrase my post in a concise way. I just notice that you can also revoke not anymore valid (expired) certificates as well. An action that was not at all obvious to me. However, from what I am now seeing, it seems to be how they should be handled, since an effect of it is to update the Removed field to 1, thus preventing the Upgrade Agent task to select the expired certificates while created.

Sure. I have two sets of certificates: one is an old pair, linked to an old certificate authority built in 2016. The certificate authority is still valid, but the actual agent and server certificates are not any more. They are flagged in red on the board (which is annoying, but I can live with it.) The other certificate authority was built in 2020, there are two valid certificates for server and agents, the server and all the agents are using it, particularly since there is a task in place for connected agents to switch to it. Everything OK here. Now comes the upgrade to 9.0. the automated process upgraded the console, the local agent and the server, keeping the valid certificates. Until there, no problems. Then I am upgrading the agents. In the past I settled as the easiest way is to push the installation of the agents, particularly since there is an option to select the latest available version. It has the nice property to be the way to go when installing a new computer, which occurs more often than upgrading ESET PROTECT. However, when I visited this area of task planning, the previously working task is now shown in yellow, marked "the referenced peer certificate is not available." Editing it, at the Settings page, under Certificate settings, the not-valid peer certificate is shown and selected, but I cannot change it for the now valid one. Worse, when I create a new task, the same problem occurs: the old certificate is selected, and there is no way to change the selection (the only other option is to use another, new, "custom certificate", importing a PFX.) I sort-of solved the problem by setting to 1 the Removed field in the SQL database, but I do not feel this is the way it should work. Perhaps I should have changed it before the certificate went invalid; however it does not seem clear to me I can use that kind of task and select a certificate which is not the earliest one. In other words, when one agent certificate is expired, that kind of task is basically unusable. Now while answering you, particularly the "components upgrade task" part, I notice there is another path, namely a client "ESET PROTECT Components Upgrade" task, aptly described as "Upgrade client (after server upgrade)." I think I was advertised of it when upgrading (but the dialog dismisses when upgrade starts, there are no links to the actual task, and there was no obvious hint that I should use it after the restart.) When I look at the previous such tasks (which means I used in the past, perhaps at the last upgrade?) I notice they are flagged in yellow because "the referenced repository package is not available", which is a correct description. Obviously, the newly created one is pointing at PROTECT 9.0.1144.0. Also, here I can edit the old tasks. Using these tasks now work and the client agents are now upgrading; but since it was after I solved the above problem, I cannot be sure having "removed" the old certificate using SQL had any influence.

Hi: Currently running version 9.0.1144. I have issues with some old certificates issued in 2016, no longer in use, which are giving me headaches. The CA certificate that was issued then was for 10 years, i.e. until 2026. The certificates themselves were emitted for 5 years (so they are expired.) But the status shows as "Certification Authority has already expired." Is it just an UI glitch without consequences? Is there some way to remove such old certificates from the database? Or perhaps remove them from being considered? I found a 2015 thread this about, where Peter Randziak sort-of promised some enhancements, but I am unable to find where such enhancement has been installed. My main issue is that for reason I cannot understand, the Upgrade Agent task is selecting that expired certificate instead of the one which is valid and in use. What is really strange is that I used the same task month ago, and it selected the correct certificate then. Any hint?

Hi Martin, Thanks for the hint. And as it came out, you were right on target: the problem was with the network (the server is multi-homed and was missing the route backward to the remote subnet). And a simple ping at the right place (or a good sleeping night) was enough to solve it. Nothing related in any way to the ESET products, 🙂 Case solved.

I recently installed a permanent site-to-site connection for a remote place. Thus the workstation there is in a different subnet (192.168.170.0/24) than the rest of the computers, and the rest include the ERA server (192.168.100.249). As far as I can [now] tell, it worked (no irrelevant message in trace.log, and I did have informations for the workstation, regularly updated). Then I migrated the EMSC server to PROTECT (8.0.1238, new database, new machine now with 2 NIC), and I upgraded security to advanced (SHA2), and renewed all certificates. Now the ERA agent there is not connecting (all the "nearer" computers are OK). It happened with the old 7.0.577, and it continues to happen with up-to-date agent 8.0.1238. Here is the relevant part from status.html (Last replication) ERROR: InitializeConnection: Initiating replication connection to 'host: "192.168.100.249" port: 2222' failed with: Request: Era.Common.Services.Replication.CheckReplicationConsistencyRequest on connection: host: "192.168.100.249" port: 2222 with proxy set as: Proxy: Connection: :3128, Credentials: Name: , Password: ******, Enabled:0, EnabledFallback:1, failed with error code: 14, error message: Connect Failed, and error details: Replication details: [Task: CReplicationConsistencyTask, Scenario: Automatic replication (REGULAR), Connection: 192.168.100.249:2222, Connection established: false, Replication inconsistency detected: false, Server busy state detected: false, Realm change detected: false, Realm uuid: 65418658-44fc-4b84-8e61-cffdb9128a9b, Sent logs: 0, Cached static objects: 3, Cached static object groups: 1, Static objects to save: 0, Static objects to delete: 0, Modified static objects: 0] All replication attempts: 52 Here are the lines from most recent trace.log: 2020-12-16 15:48:03 Error: CReplicationModule [Thread 1530]: InitializeConnection: Initiating replication connection to 'host: "192.168.100.249" port: 2222' failed with: Request: Era.Common.Services.Replication.CheckReplicationConsistencyRequest on connection: host: "192.168.100.249" port: 2222 with proxy set as: Proxy: Connection: :3128, Credentials: Name: , Password: ******, Enabled:0, EnabledFallback:1, failed with error code: 14, error message: Connect Failed, and error details: 2020-12-16 15:48:03 Warning: CReplicationModule [Thread 1530]: InitializeConnection: Not possible to establish any connection (Attempts: 1) 2020-12-16 15:48:03 Error: CReplicationModule [Thread 1530]: InitializeFailOverScenario: Skipping fail-over scenario (stored replication link is the same as current) 2020-12-16 15:48:03 Error: CReplicationModule [Thread 1530]: CAgentReplicationManager: Replication finished unsuccessfully with message: InitializeConnection: Initiating replication connection to 'host: "192.168.100.249" port: 2222' failed with: Request: Era.Common.Services.Replication.CheckReplicationConsistencyRequest on connection: host: "192.168.100.249" port: 2222 with proxy set as: Proxy: Connection: :3128, Credentials: Name: , Password: ******, Enabled:0, EnabledFallback:1, failed with error code: 14, error message: Connect Failed, and error details: Replication details: [Task: CReplicationConsistencyTask, Scenario: Automatic replication (REGULAR), Connection: 192.168.100.249:2222, Connection established: false, Replication inconsistency detected: false, Server busy state detected: false, Realm change detected: false, Realm uuid: 65418658-44fc-4b84-8e61-cffdb9128a9b, Sent logs: 0, Cached static objects: 3, Cached static object groups: 1, Static objects to save: 0, Static objects to delete: 0, Modified static objects: 0] I have tried (using reinstall) to set up the agent to connect with either a DNS name or an address (the server certificate have both alternate subject names), but both fail. I checked DNS resolution and IP routes, seem clean; I do not believe there are any router performing NAT (or PAT) while routing; at both gateways, I see the agent sending something (260 bytes) but there is no answer. At the Windows firewall of the server (firewall.log), I do not see anything dropped. I tried a telnet session from the remote place on port 2222, but it times out. I read Marcos' post about a similar issue yesterday, and perhaps it could be an issue with certificate inspection. But since the site-to-site connection have not changed in the meanwhile (i.e., it worked with SHA1 certificates and fails with SHA2???), I am not sure how to troubleshoot it; of course there is a lot more traffic which goes through the same tunnel, part of it with certificates, and nothing seems dropped. There is something which is definitively different with certificates however: earlier, the old server certificate was of "Server at *" kind (only SAN=DNS:*); while the new one is somehow more restrictive: it have just the DNS name (actually a CNAME) of the server and its IPv4 as SAN. But if that is wrong, I would like to understand why...

Did you check whether the CA (Certification Authority) certificate of ERA is properly installed as Trusted Root Authority in the System (Computer) certificate store of the server? Alternatively, if you are concerned about least security allowance, this CA authority could be restricted to either Network Service account, or the ERA server service; but it should be allowed as trusted root somewhere for SChannel to be able to validate the incoming certificate presented by the agents without warning.

Yeah, it works much better now! (I used Server_x64 v.6.1.440.0) Thank you very much Michal. @katbert: Perhaps this topic could be marked as solved then?

Same problem here, with Server-6.1.365.0_x64. SQL server is 2008R2 Express running on Spanish locale, using Windows authentication, I changed the default locale from Spanish to English of the login used without any visible effect. I spent some time on the SQL error, was able to repro the problem and found it is in fact a conversion error, as vfiuchcikicshuusrch described in https://forum.eset.com/topic/4213-critical-error-executing-database-script/?p=24318. So I designed a patch (below and 4_init_data.sql.patch.txt) which allowed me to perform the initialization of the data. --- 4_init_data.orig Wed May 20 19:32:18 2015 +++ 4_init_data.sql Wed May 20 19:30:32 2015 @@ -73,8 +73,8 @@ GO INSERT INTO tbl_security_users (user_id, user_uuid, user_login, user_comment, password_change_timestamp, change_password_on_next_logon, password_expiration_interval_in_days, auto_logout_time_in_minutes, user_full_name, user_email, user_phone, user_state, disabled, native, removed, user_password_hash, user_password_salt) VALUES - (5, dbo.ufn_uuid_str_to_binary('00000000-0000-0000-7002-000000000001'), 'system', '', '2012-01-26 12:00:00', 0, 1500, 10, 'System user', '', '', 0x, 0, 1, 0, 0x20, 0x20), - (6, dbo.ufn_uuid_str_to_binary('00000000-0000-0000-7002-000000000002'), 'Administrator', '', '2011-10-12 12:00:00', 0, 1500, 10, 'Administrator', '', '', 0x, 0, 1, 0, 0x0FCF62F35B4D4A5C1D733280F9D476E73FCBD029, 0x75A308F8F28B096A5ADFE94A07DBE5C4555E1CD3D7E43D2D23F850B5ECDEDFB56D13A85BCEE4F13D2C5E9ACB8E685D5FB6ADA597A7A22FA3E874ED65D5A6A55B); + (5, dbo.ufn_uuid_str_to_binary('00000000-0000-0000-7002-000000000001'), 'system', '', '2012-01-26T12:00:00', 0, 1500, 10, 'System user', '', '', 0x, 0, 1, 0, 0x20, 0x20), + (6, dbo.ufn_uuid_str_to_binary('00000000-0000-0000-7002-000000000002'), 'Administrator', '', '2011-10-12T12:00:00', 0, 1500, 10, 'Administrator', '', '', 0x, 0, 1, 0, 0x0FCF62F35B4D4A5C1D733280F9D476E73FCBD029, 0x75A308F8F28B096A5ADFE94A07DBE5C4555E1CD3D7E43D2D23F850B5ECDEDFB56D13A85BCEE4F13D2C5E9ACB8E685D5FB6ADA597A7A22FA3E874ED65D5A6A55B); GO (basically, changed the format of the datetime constants to include the ISO8166-mandated 'T'.) Then I inserted at installation time. That trick worked. However, the installation stopped a little later, as the log now shows: MSI (s) (EC!60) [19:34:57:546]: Creating MSIHANDLE (646) of type 790531 for thread 4960 INFO: (GetDatabaseServerConnectionStringWithoutEscape) Created connection string: 'Driver=SQL Server;Server=MYSQLSERVER,12345;Trusted_Connection=yes;CharSet=utf8;' MSI (s) (EC!60) [19:34:57:546]: Closing MSIHANDLE (646) of type 790531 for thread 4960 MSI (s) (EC!60) [19:34:57:546]: Creating MSIHANDLE (647) of type 790531 for thread 4960 INFO: Entering function: void __cdecl Era::Setup::Common::CustomActions::CDatabaseWrapper::DropAndCreateDatabaseForDBServer(const class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > &,const class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > &,const class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > &,const class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >) MSI (s) (EC!60) [19:34:57:546]: Closing MSIHANDLE (647) of type 790531 for thread 4960 MSI (s) (EC!60) [19:34:57:733]: Creating MSIHANDLE (648) of type 790531 for thread 4960 INFO: (DropAndCreateDatabaseForDBServer) Skipping file C:\ProgramData\ESET\RemoteAdministrator\Server\SetupData\Database\SQLServer\CreateScripts\version.ini MSI (s) (EC!60) [19:34:57:733]: Closing MSIHANDLE (648) of type 790531 for thread 4960 MSI (s) (EC!60) [19:34:57:733]: Creating MSIHANDLE (649) of type 790531 for thread 4960 INFO: (DropAndCreateDatabaseForDBServer) Processing file C:\ProgramData\ESET\RemoteAdministrator\Server\SetupData\Database\SQLServer\CreateScripts\1_create_schema_without_views.sql MSI (s) (EC!60) [19:34:57:733]: Closing MSIHANDLE (649) of type 790531 for thread 4960 MSI (s) (EC!60) [19:35:09:832]: Creating MSIHANDLE (650) of type 790531 for thread 4960 INFO: (DropAndCreateDatabaseForDBServer) Processing file C:\ProgramData\ESET\RemoteAdministrator\Server\SetupData\Database\SQLServer\CreateScripts\2_create_log_tables.sql MSI (s) (EC!60) [19:35:09:832]: Closing MSIHANDLE (650) of type 790531 for thread 4960 MSI (s) (EC!60) [19:35:30:632]: Creating MSIHANDLE (651) of type 790531 for thread 4960 INFO: (DropAndCreateDatabaseForDBServer) Processing file C:\ProgramData\ESET\RemoteAdministrator\Server\SetupData\Database\SQLServer\CreateScripts\3_create_views.sql MSI (s) (EC!60) [19:35:30:632]: Closing MSIHANDLE (651) of type 790531 for thread 4960 MSI (s) (EC!60) [19:35:30:632]: Creating MSIHANDLE (652) of type 790531 for thread 4960 INFO: (DropAndCreateDatabaseForDBServer) Processing file C:\ProgramData\ESET\RemoteAdministrator\Server\SetupData\Database\SQLServer\CreateScripts\4_init_data.sql MSI (s) (EC!60) [19:35:30:632]: Closing MSIHANDLE (652) of type 790531 for thread 4960 MSI (s) (EC!60) [19:35:31:084]: Creating MSIHANDLE (653) of type 790531 for thread 4960 INFO: (DropAndCreateDatabaseForDBServer) Processing file C:\ProgramData\ESET\RemoteAdministrator\Server\SetupData\Database\SQLServer\CreateScripts\5_reports_interface.sql MSI (s) (EC!60) [19:35:31:084]: Closing MSIHANDLE (653) of type 790531 for thread 4960 MSI (s) (EC!60) [19:35:31:536]: Creating MSIHANDLE (654) of type 790531 for thread 4960 INFO: (DropAndCreateDatabaseForDBServer) Processing file C:\ProgramData\ESET\RemoteAdministrator\Server\SetupData\Database\SQLServer\CreateScripts\6_cleanup_operations.sql MSI (s) (EC!60) [19:35:31:536]: Closing MSIHANDLE (654) of type 790531 for thread 4960 MSI (s) (EC!60) [19:35:31:552]: Creating MSIHANDLE (655) of type 790531 for thread 4960 ERROR: (DbCreate) La conversión del tipo de datos varchar en datetime produjo un valor fuera de intervalo. MSI (s) (EC!60) [19:35:31:568]: Closing MSIHANDLE (655) of type 790531 for thread 4960 MSI (s) (EC!60) [19:35:31:568]: Creating MSIHANDLE (656) of type 790531 for thread 4960 INFO: Successful GET property 'P_SILENT' with value - MSI (s) (EC!60) [19:35:31:568]: Closing MSIHANDLE (656) of type 790531 for thread 4960 MSI (s) (EC!60) [19:35:31:568]: Creating MSIHANDLE (657) of type 790531 for thread 4960 "La conversión del tipo de datos varchar en datetime produjo un valor fuera de intervalo." means in English "Conversion of data type varchar into datetime produced an out-of-range value." I do not know if this is the same error message as reported in vfiuchcikicshuusrch's message (in Russian), but I highly suspect it is... Unfortunately, there is no helpful INFO hint just above to explain where the failed conversion took place. I had a look at the tbl_security_groups_to_users table, and found that the "user_password_xxx" values for user 6 ("Administrator") were changed to strings of ? (0x3F3F3F3F3F3F3F3F3F3F for _hash, 0x3F3F3F3F3F3F3F3F3F3F3F3F3F3F3F3F3F3F3F3F3F3F3F3F3F3F3F3F3F3F3F3F for _salt), while the datetime values were apparently correct. [ Edit: credit vfiuchcikicshuusrch's research on the subject, which I apparently repeated. ]

I am planning the upgrade from ERA5 to ERA6 (in a SBS2011 environment). There already is SQLServer 2008 R2 running, in fact already several instances, with backups etc, of which I intend to re-use one. However I am not all clear about the architecture. In the installation guide about SQL Server installation (and in various other places, like the specific guide about SBS), login mode is to be changed to use "mixed mode", that is both "SQL login" along with Windows authentications. Later (§3.7.1 Server installation), the connection from the server is specified to be either with login or using integrated Windows. Then at §3.7.5 Proxy installation, there is another (ODBC) connection to be created; this time there is no specification about which authentication mode to use; I guess both should be valid at this point. Since this is a small network, there is no requirement for a proxy anyway, is it? Then at §3.7.6 Mobile Connector installation, there is another database and another connection to be created, again specified to be either with login or using integrated Windows. I do not have Mobile Devices anyway, so it does not matter much. The HTTP "mirroring" proxy at §3.7.8 does not use database connection; and the web console does not seem to use it either, does it? So at the bottom of the day, it seems that I can fly with Windows authentication, and can avoid the need to create and maintain SQL logins altogether. Is there something I missed at some point?