Jump to content

antoineL

Members
  • Content Count

    6
  • Joined

  • Last visited

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 (
  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
  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
×
×
  • Create New...