Jump to content

MartinK

ESET Staff
  • Content Count

    1,893
  • Joined

  • Last visited

  • Days Won

    61

Everything posted by MartinK

  1. Could you please provide some screenshost to helps us understand where exactly is problem? Maybe it is related to fact that re-calculation of version check results is performed with delay (should be no more than 1 hour), it might render not current or undefined status in dashboards.
  2. From provided schema I am not sure where could be problem. In case pink clients have access to "Web Server", they should have access also to ESMC. Maybe router1 and router2 are blocking communication on port 2222? Otherwise in case there is standard NAT used, it should work. Can those clients ping ESMC server? Ping should also verify correct routing is used, even in case ping itself will fail due to firewalls not allowing it.
  3. Seems that each attempt of installation created new set -> I would recommend to perform complete reinstall in case you have not performed any actions or deployment yet. Those certificates can be "revoked" which would probably results in removal from console, but might be cleaner to just reinstall (uninstall with database removal + install).
  4. Unfortunately crucial part of log is missing (lines are not whole), but I think that most relevant error would be: Execution test of long statement failed with DATABASE exception which indicated that MySQL is not configured properly. There are certain configuration requirements as described in documentation. Error indicates that parameter max_allowed_packet is not configured properly, but there are also two other settings that has to be changed and are checked during installation. I would also recommend to check original log for missing part, as DB error that caused failure of this check might be different, not related to value itself, but I do not think it will be communication nor authentication issue as prior to configuration check there was successful connection check performed.
  5. It is almost impossible to help in such situation without details. But regardless of network topology, you have to configure network in a way that ESMC Agent can connect to machine where ESMC Server is installed using port 2222 (no need to do so for 2223, it is used only for console access and so called server-assisted installation). One possibility might be exposing ESMC Server's port even in case it is behind NAT router, or placing ESMC Server into DMZ part of network. Also it might be possible to use HTTP proxies to route communication of ESMC Agent's to ESMC. Last, and most commonly used might be hosting ESMC Server in cloud (i.e. hosted on machine in cloud providers environments) and thus enable all ESMC Agent with internet access to connect.
  6. Yes, it will revert back to settings from policies.
  7. I am not certain but it seems that HW fingerprint of this device change in a way that ESMC requires manual approval for this device - it might have been evaluated as cloned. Could you please check this client's details in console, whether there is no "Question" in respective subsection? It should be indicated by blue number. Also such questions from whole network should be listed in "Status overview" dashboard, if there are any. If question will be reported for this device, please check documentation for it and resolve -> once done, device should be connecting.
  8. I would recommend to start by checking AGENT logs, as described in connectivity troubleshooting section of help. Please also verify that AGENT service is actually running.
  9. Problem was, that AGENT was connecting to "127.0.0.1" but ESMC's certificate is signed only for *.mydomain.it, mydomain.it, i.e. all AGENT's has to be configured to connecto to hostname matching regular expression *.mydomain.it. As it started to work after redeploy, locally installed AGENT is now probably using also fully qualified name of ESMC.
  10. I have not verified, but in case you download EEA 7.2 from global webpage (i.e. not Japan page), installer will most probably contain Japan locale, i.e. it will install with Japan locale on Japan systems. It might happen that once there will be EEA 7.2 for Japan, it will be actually new build with additional fixes. Maybe @Marcos can also help to confirm, how is it with support of Japan locale in global releases.
  11. In case changing login credentials to your AD/LDAP won't help, I would recommend to contact ESET support to provide help. Unfortunately LDAP synchronization has very complex configuration - but in this case there is definitely problem with authentication.
  12. Could you be please more specific? You have created mapping for AD security group but users from this group are not able to log in? Asking because it is not clear, as users won't be automatically shown until they first log-in into ESMC, nor they will be removed from ESMC once removed from AD.
  13. This specific client is not able to resolve DNS name of your ESMC, i.e. error is: GRPC:Failed to resolve: eset-es.<redacted>.com:2222 Could you please verify that clients can actually resolve this hostname? There is an alternative to instruct clients to connect to both hostname and IP as an alternative, but it has certain requirements to ESMC's TLS certificate so should be used carefully.
  14. Unfortunately I am not able to provide any official recommendation, but any chance you tried third-party repositories? For example this one seems to provide QtWebkit based on Ot4: https://centos.pkgs.org/8/getpagespeed-x86_64/qtwebkit-2.3.4-23.el8.x86_64.rpm.html
  15. Please check file: /etc/opt/eset/RemoteAdministrator/MDMCore/StartupConfiguration.ini It contains connection string for MDM application. I just noticed that your original version was 6.5 which was bundled with ODBC 5.3 driver, so application was broken during upgrade to ODBC -> i.e. application expects 5.3 ODBC driver. My recommendation, and also recommendation for users (that I cannot find currently) was to revert ODBC driver to older vesion and configure system in a way that version of driver will be frozen, i.e. it won't be updated due to possible incompatibilities. I hope that steps as described in article: https://saputra.org/threads/eset-security-management-center-login-failed-connection-has-failed-with-the-state-not-connected.56/ should be sufficient. Problem is most probable in fact that MDM As an alternative, it would be possible to modify StartupConfiguration.ini file in a way that ODBC driver "MySQL ODBC 8.0 Unicode Driver" is used, but I cannot guarantee MDM will work properly with latest driver: but it is easiest possible fix.
  16. Please check MDM's trace log located in: /var/log/eset/RemoteAdministrator/MDMCore/ for any clues. It seems as if process is crashing or is aborted: we have seen similar behavior when incompatible ODBC drivers was used. There are certain versions of MySQL ODBC drivers that have an issue triggered by our DB layer, resulting in intimidate process stop. I would recommend to revert MySQL ODBC driver version to one that was previously installed in appliance (8.0.11). We have recently updated list of supported/working drivers in help pages (https://help.eset.com/esmc_install/71/en-US/database_requirements.html) as event latest released MySQL drivers are also not compatible.
  17. In case of silent upgrade from terminal, running: ./MDMCore_x64_64.sh --skip-license from root terminal should silently upgrade your MDM. In case of manual upgrades performed via Webmin, there might be theoretically problem with SELinux, so I would also recommend to temporarily disable SELinux using commend: setenforce 0 and verify whether it helped to start service.
  18. Error indicates you are using wrong ODBC driver configuration, i.e. you have probably specified ODBC driver that is not available in the system. In case of upgrade, I would recommend to perform it from terminal, where it will be perform without any interaction, especially in case you follow these steps: Open Administrator command line, i.e. start cmd.exe ad Administrator. Run command: msiexec.exe /qn /i MDMCore_x64.msi /l*v C:\mdmcoremsilog.log which will start upgrade in the background. Please adapt parameters to you environment -> logging might be omitted by I would recommend to perform upgrade with full msiexec logging just to be sure it is available in case something goes wrong. Wait until upgrade is finished. As operation would be performed in background, I would recommend to check log after some time and search for operation result status.
  19. Problem is unfortunately in ESMC itself, but actually issue is that ESMC is offering to create Japaneses installer with version, that is not available in such locale (not yet released). Workaround in this case would be to select manually version that is available in Japanese locale, which is for example 7.1.2053.1 (currently latest with this locale).
  20. Could you please provide more details of why would you need to have access to workstation ID? As you mentioned, it is currently used only as a backup for recovery in case it is not possible to recovery device from data provided in client details - in other words, it it supposed to be a fallback for cases where client is no longer managed in ESMC or hardware was changed (i.e. disk moved to different device). This is currently intentional due to security. Searching recovery data bypasses standard security mechanisms used in ESMC, based on static groups hierarchy and thus access to this "fallback" for recovery is available only for users which has access to all devices, and thus leak of data to non-privileges users is not used. We will probably reconsider this approach if suitable solutions will be found, without risk of leaking data or loosing access to recovery data.
  21. Just for verification, creation of upgrade components task requires you to specify "target" version -> have you chosen 7.1? It is also possible to use ESMC 7.1 bootstapper (all in one installer) downloadable from ESET web: since latest version it offers upgrade of all main components, including Server, Webconsole and Apache Tomcat.
  22. Just to be sure, there is no configuration policy present in ESMC with old IP address in configuration? Regardless possibilities, one last might be to use manual repair (i.e. manually run standalone installer) and provide settings manually. Unfortunately live installer script (BAT) has a glitch and it reports success even in case it actually fails to deploy AGENT, so it is still possible that live installer itself is not working (or was it clear from output to console that is succeeded?). It might be for example just problem with package download in customer's network. In this case using all-in-one installer, which embeds packages might be possible workaround.
  23. In that case it will be most probably issue we have encountered recently -> for some reason it seems that we get notification from system sooner that user data is actually available and thus we "miss" logged user details. It should probably recover after login/logout or after new use is logged in, but that is not common scenario on macOS systems ...
  24. In case ESMC agent has connected since you logged-in, I would expect it has to report it. Are you using Windows or macOS desktop? Asking, because we have recently analyzed issue where on macOS detection was not working properly.
  25. My best guess would be that in such case, devices without any logged in users are not shown - could you please verify?
×
×
  • Create New...