MartinK

Yes, it will revert back to settings from policies.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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).

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.