MartinK

In that case I would recommend to fetch AGENT's configuration via console and check what hostname they were actually using, so that you can possibly return back or create certificate with specific hostname.

Not sure I understand correctly what is meant by migration, but in case it is meant to be change of database type without loosing any data, than this is not possible due to missing tooling and differences in data organization between MySQL and MSSQL. In case of database type change, only alternative is to: perform fresh installation of ESET PROTECT - this will create "empty" database on DB server of your choice configure new server in a way client can connect to it (i.e. server on the same hostname, the same certificates, i.e. scenarios from documentation: https://help.eset.com/protect_install/90/en-US/?db_migration.html) manually migrate various data from old server to new, including devices hierarchy, policies, dynamic groups, etc. but be aware that during this process, historical data sent from devices will be lost, including various detection reports, etc.

Could you please elaborate more on "I adjusted hostname used by the client"? It is crucial that clients are configured to connect to exactly the same hostname as is "signed" in the certificate. This is especially true in case ESET PROTEC's certificate is using specific hostname and not a wildcard (*). Otherwise this error indicates there is either network error, or TLS handshake is not finished properly - where one of the reasons might be that PROTECT is rejecting client's certificate - therefore more reasonable error might be present in PROTECT's trace.log.

Just be aware that when doing so (removing active device), it might happen that data stored for such device will be removed with no possibly to restore such data - this includes especially various detection logs from past. Whether this happens depends on when data cleanups are executed, which is randomized, so removal is not guaranteed until device is not in "removed" state for longer than a day. Also note that "objects" such as configuration policies or tasks assigned directly to such devices will be invalidated, so removal should be done with care.

I would recommend to test locally to find out how to adapt it - what happens when task is executed is that standard BAT file is created with content of task configuration (with some pretty standard encoding-related commands in the beginning), so it is crucial to find out how such BAT file can be created. There are definitely few special characters that has to be escaped to be used in BAT file, for example "%" and possibly also "!".

Please check my comment in one of recent topics: https://forum.eset.com/topic/30411-eset-protect-dashboard-agent-is-not-working/?do=findComment&comment=142648 as it seems to be related. In short, there is a different approach when ESET PROTECT upgrade is required, especially for devices hosting one of our server-based components (PROTECT Server and MDM).

From description you provided it seems, that the same license was added into console using two methods: Added license by it's key, either manually in the console or even during deployment of console itself (indicated by key icon) Added license by EBA accounts (indicated by EBA account and person icon in the list) Solution to this might be to consolidate this list. I would recommend to first: Add the same license using your EBA account, just to verify it will work Remove original copies of the same license, i.e. the one tied to old/unused EBA account and the one entered by key Correct existing activation, deployment and installer tasks, ad they are most probably referencing licenses that you just removed - tasks and installer will be marked as invalid and won't work until they are updated with proper licenses Removing and re-adding licenses won't have any impact on products functionality (they will remain activated) but new deployments and activation might fails from the console in case tasks won't be updated after license re-adding.

Not sure I understood correctly, but in case there is a problem with configuration of WebConsole (= i.e. issue with headers), you will have to check and possibly adapt configuration of "Apache Tomcat" and not "Apache HTTP Proxy". As you mentioned, our application most probably uses correct configuration, but root page is most probably using default configuration of Apache Tomcat, which might explain why such headers are missing.

As you mentioned, server version is prerequisite, i.e. AGENTs will be upgrading only to version that is "compatible" with ESET PROTECT server itself. As of now, latest AGENT version compatible with ESET PROTECT 8.1 is also version 8.1. This correlates with version of AGENT as present in installer created in the console and version check.

Unfortunately this one-click mechanisms is not available for ESET PROTECT components and so called "components upgrade task" has to be executed manually on such device to make it upgraded. Also note that this task will upgrade all ESET PROTECT components on the device - including AGENT itself. In case AGENT is already upgrade and this type of task was executed there, I would recommend to double check it has not failed - but it is possible AGENT was not upgraded, as we do not offer one-click upgrade for devices where server-based PROTECT components are present, due to possible impact it might have in case of failure.

Unfortunately that is not enough as installers do contain only CA certificate and certificate for AGENTs, but for restoring connectivity, it is crucial to get certificate for ESET PROTECT Server, which is much more "sensitive" and it is normally stored only in it's database, especially public part that is required in this case - in other words, this certificate can be recovered only from database or manual export. This is due to security reasons, as leak of such certificate would enable possible "attacker" to get hold of the managed devices...

In order to recover connectivity of already installed clients, it would require you to restore ESET PROTECT certificate and respective CA certificate - where both of them are store in PROTECT's database - so it depends on what means "crashed" . Alternative, but more complicated solution is to re-deploy or use installation repair of AGENTs with new parameters, i.e. reinstall or modify existing AGENTs with newly created certificates. For this purpose, any deployment method can be used, so also GPO "script", etc.

Indeed AGENTs should upgrade automatically, but there are certain delays and randomization involved, which means that this process won't start sooner than 2 weeks after release and will be distributed randomly throughout upcoming weeks. In case more control of upgrade time is required, original tasks might be used as with older releases.

I can image two separate issues but cannot be precise as it require more data to be provided: Either ESET PROTECT's certificate was changed in a way that existing clients do not trust this certiifcate - i.e. those clienst might not received new CA certificate in time. This might be the reason why new installer helped - as it bundles CA certificate required for verification of this certificate Clients are not connecting due to other reasons: for example TLS incompatibility. My expectation is that first scenario is the case - solution might be to temporarily revert/use original ESET PROTECT certificate, at least until both new and old CA certificate are distributed to all clients.

In case you meant detection logs in diagnostic severity, it is currently not possible to enable it globally due to performance/network traffic impact it has on console itself. This is reason why such logs can be requested only manually for specific devices, and also only for limited time (24 hours If I recall correctly).

No, there must be a different issue. Could you check client details of device where EP Server is installed, whether it is not reporting wrong version of your ESET PROTECT Server? Is this AGENT actually connecting? If not, that might be the reason as version detection relies on version as reported by managing AGENT. Also previously we have seen this issue triggered by presence of another ESET PROTECT Server instance in the network, but I guess this is not this case as issue was resolved some time ago.

So there are multiple alternatives: technically it is indeed client task, called "Components upgrade task" (might slightly differ in specific locations or version of the console). In this task you specifies version of your PROTECT server, and once it is executed on client machine, it will upgrade AGENT (and possibly other components) to version compatible with selected PROTECT Server version. It is on background the same, but you can use one-click mechanisms as offered in dashboard: just click on AGENT's column and update action will be offered: Last alternative is to wait for auto-upgrade of AGENTs to be executed. This will work only for AGENTs 8.1+ and it cannot be disabled in configuration policies. As an results, AGENT should be upgrade to latest compatible version after some time (few weeks after PROTECT 9.0 upgrade), i.e. it is distributed in a time to not have serious impact on network and to not risk immediate upgrade.

Have not tried, but it should be fairly easy, as management console is using Apache Tomcat for hosting console. There are even steps in documentation of Certify the Web: https://docs.certifytheweb.com/docs/deployment/tasks/tomcat/. Only possible issues might be with pfx type of certificates - we have seen previously it might not work in all environments, which would require you to convert certificate to different container format (ideally Java - jks format).

I would recommend to start by mentioned SQL and modify server_identificator in the table tbl_servers, but I am not sure this is actually enought for enrollment of mobile devices, but at least is should not breaking anything. Also note that hostname present in this DB table is shown in generated reports.

Could you please provide more details of what type of deployment are you using? Also any chance this has recovered after some short time? Any chance some kind of revert of machines was used either of EP server itself or endpoint devices?

It is hard to evaluate risks as it depend on how management console will be used and how access rights are configured there, but what you can expect is that once device is managed remotely, user of console will possibly have administrative access to your device, as security products tend to have access to system and all files (for purpose of scanning). In terms of macOS, it technically means that remote administrator will be able to perform actions that normally only root user can. Possible actions might be limited for specific console users, but there will still at least one administrator that will have full access, which you might consider as an risk in case you have no visibility nor control of how access rights are configured in the console.

From provided error it seems that appliance (as an operating system) is not able to verify certificate of your domain/LDAPs server. This will probably require installation of your CA certificate (used to verify certificate of your LDAPS server) into the operating system itself, so that also system tools do work properly and device can be joined.

Could you please provide failure reason of such deployments in the console? In history of task execution, it should be visible in what step it failed - maybe it was installed correctly, but there was some activation issue. Also note that EEI Agent might require some approval in the system (full disk access and maybe also approval of system extensions), which might also block it, until it is resolved locally or via Apple management solution.

Thanks for point this out - it makes no sense to me, as "component upgrade task" has never been capable of upgrading Apache HTTP proxy. It is possible that manual "migration" of settings was required after upgrade from much older versions, where mentioned path was used. In case of appliance, Apache HTTP proxy is updated as a standard system component from official CentOS repositories, and that is moment when configuration might be theoretically modified. The same applies for upgrade of appliance using "migration" where custom configuration has to be moved manually, but in case you made not changes, risk is almost non-existing.

Unfortunately this is not configurable - timestamps in exported data are always using UTC/GMT timezone, so that data from devices with different timezone can be correlated. Any chance this is configurable in Splunk itself?