MartinK

ESET Staff
 View Profile  See their activity

  • Content count

    978

  • Joined

  • Last visited

  • Days Won

    30

MartinK last won the day on October 2

MartinK had the most liked content!

Kudos

110 Advisor

See kudos

1 Follower

About MartinK

  • Rank
    N/A

Profile Information

  • Gender
    Male

  1. Cannot add license in ERAconsole

    MartinK replied to superzpy's topic in ESET Remote Administrator

    This certificate should by trusted by system itself, as it is distributed by windows update system (see list of trusted CA certificates) -> it is the one with thumbprint F1:8B:53:8D:1B:E9:03:B6:A6:F0:56:43:5B:17:15:89:CA:F3:6B:F2. What operating system version are you actually using? If I recall correctly, ERA should contact ESET servers (pki.eset.com -> see list of IP addresses in documentation) - any chance you are actually blocking this URL? Asking because trace.log shows that there were problem with contacting ESET servers some time ago. I would recommend to check whether operating system it updated, especially whether Windows root certificates are up-to-date. It is also possible to download required certificate from Thawte official pages and import in into "Local system" store, as was described in article I mentioned in previous post.
  2. MartinK started following Last Connect, Scheduled On-Demand Scan task are not triggered automatically from ERA., ERA Virtual Appliance Migration / Upgrade v6.2 to v6.5 and and 5 others
  3. You trigger is configured to end after 10 executions, which means that each client should execute this task exactly 10 times (even failures count). Seems that trigger is active since 19th September - any chance "problematic" clients already executed this task 10 times since?
  4. I don't think it is necessary in case HTTP is disabled by global configuration. Changes would also require to modify content of era/ subdirectory, which could cause problems during upgrade.
  5. Redirecting HTTP to HTTP should be possible by changing Apache Tomcat configuration, see for example this article. I would recommend also to block HTTP access for security reasons. Yes, is normal that ERA Webconsole is deployed in "/era", but is is possible to use redirector so that console is accessible from root or different subdirectory. For example placing index.html file into Apache Tomcat's ROOT directory (webapps/ROOT/) with this content: <!DOCTYPE HTML> <html lang="en-US"> <head> <meta charset="UTF-8" /> <meta http-equiv="refresh" content="0;url=era/" /> <script type="text/javascript"> window.location.href = "era/" </script> <title>Page Redirection</title> </head> <body> If you are not redirected automatically, follow the <a href='era/'>link to ERA</a> </body> </html> should redirect you automatically to ERA.
  6. Just to describe what is going on, even you found working workaround. Once you initiated upgrade of whole appliance by pulling database from your older OVA, SERVER inside new OVA was installed, but once it started, it took some time until it was accessible from network, and that is reason why installation of AGENT failed, which resulted in OVA that was "optically" not working. It was actually almost ready for use, especially SERVER was already running. What actually helped in your case was re-configuration of new appliance, which technically executed "repair" over SERVER and finalized remaining operations. They were this time successful because SERVER was already upgraded and thus it took much less time to initialize. Updating system should not affect this issue. It is required to wait until SERVER is fully upgraded, which should not take more than an hour. For those than experience this issue, there are few alternatives, where the easiest and recommended is to to upgrade SERVER inside old ova appliance (components upgrade task), and once this is done, and SERVER is running, migration to new OVA may be performed.

  7. Audit Logs Gone Wild

    MartinK replied to escadan396's topic in ESET Remote Administrator

    There has been issue similar to this identified recently. Could you please try to modify your AD synchronization task so that "Computer creation collision handling" is set to "SKIP"? What version of ERA are you using?
  8. It means, that certificate it not meant to be used for hostname you are yousing to access ERA. For example, if you are accessing ERA using https://era.yourcompany.com , this exact hostname "era.yourcompany.com" or wildcard alternatives must be either in common name (CN) of certificate, or in it's extension called subject alternative names. I would recommend to check what hostnames are present in certificate itself (you will get to it when viewing certificate in browser) and either use one of those to access ERA, or ask for new created for proper hostname.

  9. Agent installation error

    MartinK replied to mogobjah's topic in ESET Remote Administrator

    Unfortunately there is not much visible in network capture, as communication is encrypted - but at least we known that there is no problem with communication over network. What is very surprising for me is that there is too much traffic to port 2223 - how many CA and AGENT peer certificates do you have in ERA console? Are you using the same ERA account to deploy on all clients (working and non working) and does this account have proper permissions to access certificates (would be true if Administrator account was used)? Are there any obvious differences between working and failing client machines (different system or platform, system language or locale, specific software)? For further analysis, we will need more detailed logs. Please provide following logs in private message because of sensitivity: full installation log from client machine. Details how to run installation with trace logging is described in ERA documentation. full trace log from ERA. This requires you to enable full (debug) verbosity in SERVER configuration, re-run AGENT installation, and copy SERVER trace log, which is most probably located in directory C:\ProgramData\ESET\RemoteAdministrator\Server\EraServerApplicationData\Logs . One trace.log file is copied, full trace logging may be disabled in SERVER configuration.

  10. SMTP configured but Test not working

    MartinK replied to nickospot's topic in ESET Remote Administrator

    I would recommend to check SERVER's trace.log file for more specific error (most probably located in directory C:\ProgramData\ESET\RemoteAdministrator\Server\EraServerApplicationData\Logs). It is just guess, but in case operation takes longer than 90 second, it is most probably caused by network problems - could you double check that your SMTP server is accessible from machine where SERVER is hosted in terms of firewall and routing configuration? Is proper port and connection security used? In case SMTP server is expecting TLS connection, using non-TLS connection type may result in connection blocked because of wrong data sent to server.
  11. Just to let you now (if you are interested in testing), changes are now available for Pre-release update servers. I guess they will be propagated to Regular update servers in a few days in case nothing goes wrong.

  12. Deleting ERA

    MartinK replied to Mr Problems's topic in ESET Remote Administrator

    Please check section Migration from one server to another of ERA documentation. It describes various migration scenarios. It should help you to migrate AGENTs to new server without need of repairing or re-deploying them manually. In case you just erase SERVER without proper steps, it will be hard to re-establish management of your network.

  13. Cannot add license in ERAconsole

    MartinK replied to superzpy's topic in ESET Remote Administrator

    I am not able to verify it now, but it seems to be problem with SSL/TLS certificate validation. Could you be more specific of your environment, i.e. windows? linux? is it updated? version of ERA? When ERA is synchronizing licenses, it is connecting to https://edf.eset.com/edf and strictly validating it's SSL certificate against certificate store of "local system" (= not against user store). Please verify that CA certificate "thawte Primary Root CA - G3" with SHA1 fingerprint F1:8B:53:8D:1B:E9:03:B6:A6:F0:56:43:5B:17:15:89:CA:F3:6B:F2 is available in computer certificate store -> it can be accessed using MMC console, search for "Adding certificates to the Trusted Root Certification Authorities store for a local computer" in the Manage Trusted Root Certificates article. Also if it is problem with certificates, it should be visible in network (wireshark) capture of traffic to edf.eset.com.
  14. MichalJ liked a post in a topic: How to connect a linux server with Remote Administrator?
  15. Moriort liked a post in a topic: How to connect a linux server with Remote Administrator?
  16. New configuration of update servers was deployed to private/testing servers during last week. Unfortunately I do not know for how long it will be tested as it is critical part of ESET infrastructure. What I can tell you is that once new configuration is deployed on public servers, caching will start to work automatically.
  17. In case Apache Tomcat started, it is highly probable that you new certificate is in use. Just to be sure, I would recommend to check that SSL/TLS is actually used. IT should be indicated by your browser. Most, if not all, browser also is able to show you certificate actually used by site / ERA WebConsole -> this can be used to verify correct certificate is used. Regarding insecure site problem, it will be most probably caused by certificate. There are multiple possibilities, for example CA certificate used to sign this certificate is not trusted by browser, or weak cryptography was used to create this certificate, or certificate was signed for different hostname than your are using to access ERA WebConsole.

  18. Last Connect

    MartinK replied to TheSkymanDC's topic in ESET Remote Administrator

    When you were checking AGENT logs on client computers, were they current, i.e. was timestamp of last successful connection recent. It is possible that AGENT is not even running and thus information in logs may be outdated. In status.html, there should be even hostname of where AGENT is actually connecting. If this is not the case, could you please restart ERA Server service and check whether it helped? We had similar issue in older version - what version (ERA Server, ERA Agent) are you using?