MartinK

Currently it is not decided of the future, and even latest version is using CentOS7-based appliance, which is supposed to be supported until 2024 (i.e. much longer than mentioned CentOS8). We currently rely on fact that security patches are available, even for tomcat 7 which is part of official CentOS7 repositories. Just out of curiosity, what would be your preferred Linux distribution for future? Asking as there is not many "free" distributions guaranteeing reasonably long support and stability of environment for future migrations.

I think that problem is that version 6.6 of macOS ESET product is not supported on macOS 11.0 (Big Sur, reported as 10.16 by older management agents) - there should be multiple KB articles regarding this, and probably only version 6.10 is capable of running on such system. Or version as reported by management agent and visible on previous screenshot is not correct?

I would recommend to employ dynamic groups to distinguish "master" from other clones, so that reset agent task is executed only on clones, not on master image. More details can be found in older topic: Unfortunately there is currently no automatic handling of cloned devices for Linux systems, so I would definitely recommend to open also support ticket and possibly let know your ESET partner regarding this requirement.

There is one special requirement for ERA/ESMC/PROTECT certificates: CN (CommonName) of certificate for ESMC Server has to contain word "server" and also it cannot contain word "agent" or "proxy". Could you please check that your certificate meets this criteria? Or is this certificate created by management console? IF so, problem might be that hostname (which is also part of CN fields) contains prohibited words.

I am just guessing, but error indicates that content of PFX is not as expected. As this certificate is used to host service, it has to contains both public and private part (private keys). Could you verify this criteria is met? I am looking at openssl command you used to create PFX file and I am not sure it actually contains private key for certificate, which would be reason for failure. Also it might explain original issues, as Tomcat will definitely require keys.

In this case, probably settings should have been forced instead of applied (this is done per-setting in configuration editor) and it impact order and priority of policies. But this will prevent just replacing settings, not merging different settings, so still it might not be proper solution for all settings. Regarding connectivity problems, what is actually current problem of AGENT? They cannot reach wrongly configured HTTP proxy? Or they are not using any proxy and thus not able to connect? I was just thinking whether there might be some other solution than manually repairing AGENTs using installers or GPO/SCCM, but it is dependent on infrastructure and possibilities you have to at least temporarily adapt it to enable connections ...

In case there will be no other possibility, so called "repair" mechanisms of installer can be used to correct communicate-relateted values. This can be achieved by manual running of standalone AGENT installer, or also executing other installer types on client machine. In case of repair, device identity should be retained, i.e. it will start connecting as if there was no interruption. Could you also describe of how "wrong" is proxy configuration? Asking especially whether there is no possibility to somehow install proxy on place where it is expected, at least until new policy is delivered to AGENTs.

This might be really hard to analyze, but I would double check that SAMBA is correctly configured on the system and properly joined into domain. As you are connection to older SMTP server, it is possible that there might be even problem with used authentication protocols, as recent SAMBA versions no longer support legacy and no-longer-secure protocol.

Unfortunately I lost ideas as there is probably some misunderstanding or some step is not working as expected. In this case, it might be helpful to use ESMC 7.2 all-in-one installer to generate propper configuration, i.e this: which would require you either to uninstall console, or even better to install console just on some testing machine, without any other components, and just migrate certstore and possibly server.xml configuration to your production server.

As I have no experience with using tomcat with PKCS12 type certificate, I would recommend to convert PFX to JKS. For this, I would use free utility "KeyStore Explorer", which you can use to edit or create new JKS keystore. Once done, just be sure permissions are properly set on new file. I do not think you have to modify list of cipher-suites.

Currently it is not possible, except maybe using some magic using "Run command task". In case upgrade using component upgrade task via console is only possibility, I would recommend to wait for upcoming major release, which will unblock upgrades also for older versions of AGENTs (once also SERVER will be upgraded to latest versions). This release should be available very soon (= this year).

I was referring to following functionalities as described in documentation: Export Static Groups Import Static Groups

Could you please clarify what certificate you are actually trying to renew or replace? Asking because certificate used by console (and set in Apache Tomcat configuration) is different from ESMC's peer certificate, that is used for AGENT-to-ESMC communication and set in configuration via console - also both certificates has different requirements and preferred formats.

Unfortunately I cannot verify, but there might a way, using export/import mechanisms of group hierarchy. This would require you to: export list of devices with hierarchy from console of original ESMC import this hierarchy into new ESMC with enabled moving of devices. This step should move exactly named devices to name as was used previously, including creation of groups.

You cannot import it into console for further management, but when setting certificate in ESMC's server settings, you can "upload" arbitrary certificate, and that is the way. As you won't be able to import it, it would be ideal to replace it later with certificate generated in new ESMC, but this will be possible once all agents are migrated to new server and actively connecting.

Not sure I understand, but both ESMC all-in-one installer and live installer created in console will be installing latest compatible version (i.e. 7.2 AGENT in case you are using ESMC 7.2). These installer can be used to manually upgrade AGENTs from older to never version.

If I recall correctly, working directory is probably set by "parent" process, i.e. it is set before script is started, and therefore it is not visible in script content directly. Regarding removal of script, in case path is correct, could you verify that script is not running? In case it is blocked on execution of first line, it might explain why delete operation was not called... Also note, that most common issue with run command taks is that scripts are executed with AGENT's security context, i.e. as LOCAL SYSTEM, which might have limited access to specific resources, including user desktop, and therefore extra care has to be made when accessing network shared, protected disks or even executing applications that might require access to desktop environment, or environment of standard user.

Just a note: for upcoming major release, we decided to relax this limitation in a way that even upgrade of legacy versions (versions that already reached it's EOL) will be possible automatically and directly, using component upgrade task.

There are actually two alternatives: You do not need to create new certificate in case old one contains "asterix" in common name, i.e. in case it was signed in a way that it can be used on new hostname. If this is confirmed, you can re-use existing SERVER certificate without creating new one. Once client are migrated, I would recommend to create new certificate on new ESMC, to be sure it has latest possible parameters and validity is extended. You can create new CA certificate and SERVER peer certificate on old ESMC server. You just has to ensure that this new CA certificate is distributed to each client before migration policy is applied - but this is automatic in case proper order of steps will be used.

Problem is, that report templates are actually also objects, that are "tied" to specific static group (= access group) and thus have limited visibility. In case of default report templates created during installation, they are configured with access group set to group "All", which means that only user which have access to "Reports & Dashboards" on group "All" will see those reports. The same applies also for other managing objects in console (policies, dynamic groups, notifications, ...). Unfortunately I cannot verify now, but there might be two solutions, where both do require some redesign of security model you are using: Users might be assigned special permission set, that will give them permission to "Use" Reports from group All - but I would recommend to double check it does not give user access to devices Move/Change access group of required Report templates so that user can see it. We have seen that especially MSPs were creating specific "Shared" static group just to share such objects between users.

Yes, that should help. If I recall correctly, this port is enabled by default in proxy configuration for some time - I guess you are using some older version or at least older httpd.conf file? Loading of module should definitely work. In case proxy is not even starting, I would double check that LoadModule statement is correct. Unfortunately I cannot verify as it seems you are using some older version - in current one, there are no dummy load statements in httpd.conf and maybe one of reason is that they were not correct, i.e. there might have been wrong path (or wrong format of path).

In case you used Apache HTTP proxy which is part of our installers, you should follow following steps: https://help.eset.com/esmc_install/72/en-US/apache_configuration.html where in short you have to: enable port 2222 in case it is not enabled already (depends on version you used) enable connections to your hostname (hostname where AGENT are trying to connect) - by default, only connections to ESET domains are enabled due to security, therefore using proxy for replication connections requires manual steps.

@Marcos: Unfortunately in this case there is probably no fallback for HTTP proxy, as it was explicitly disabled, and also "replication" proxy was set, not generic/global proxy, where we silently count with possibility that it might not support replication connections. In this case, probably only solution would be to repair installations, i.e. using AGENT installers. IS there no possibility to at least temporarily deploy HTTP proxy on "wrong" hostname/IP? Or redirect agents to other location via DNS changes? It would be probably easier ...

It might be so called "fallback mechanisms" integration into connection handler. It protects environment from some "destructive" changes in configuration, and it works in a way that AGENT will be trying to connect to last successful target in case connection to newly set (currently set) ERA/ESMC server fails. So connection attempts to old ERA Proxy are expected behavior in case AGENT are not able to connect to new ESMC. Unfortunately fallback attempt might "hide" real connectivity issues, so I would recommend to double check logs for clue why AGENT is not able to connect to new ESMC, especially if this is the case.

Just out of curiosity, which Apache module are you missing? If I recall correctly, modules required for access logs to be enabled should be present, but it is possible that they are not loaded by default in httpd.conf.