Jump to content

antoineL

Members
  • Posts

    6
  • Joined

  • Last visited

About antoineL

  • Rank
    Newbie
    Newbie

Profile Information

  • Location
    Spain
  1. 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.
  2. 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...
  3. 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.
  4. 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?
  5. 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. ]
  6. 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?
×
×
  • Create New...