MartinK

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 r

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

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, especiall

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.

Yes, in case of multiple commands, one have to enter delimited one-liner, as it would be done in one-line BAT file. Just a note, this will be improved in upcoming released, where multi-line commands will be possible, which should simplify such scenarios.

Manual upgrade of application would work normally, i.e. new version will just replace original version, even with retaining all configuration parameters and it's identity i management console. Even silent upgrade using MSI installer (without parameters) should be enough. This means that also GPO deployment should be sufficient. @Marcos: Actually Software installation task cannot be used to upgrade AGENT itself, but there are some undocumented methods using "Run command task", probably present also on this forum. Currently automated in-program updates are not enabled for older versions, th

I would recommend to verify & review migration steps made as there was probably some step skipped or missed -> most probably, clean installation of ESMC was made, before database was migrated. Unfortunately I am not sure whether it will have any impact on functionality. In order to fix inconsistency in identifiers, you will have to modify value of ProductInstanceID in windows registries on path: HKEY_LOCAL_MACHINE\SOFTWARE\ESET\RemoteAdministrator\Server\CurrentVersion\Info where ProductInstanceID has to be set to value 09864601-779e-4b48-92c5-9a32db077762 seemingly stored i

From description you provided it seems that so called managing AGENT (= agent installed side-by-side with ERA Server) is not connection. In that case, I would recommend to follow troubleshooting guide as described in documentation, where checking status.html log of AGENT might be helpfull.

Thanks for detailed confirmation. We will have to check how this character is processed -> this one is actually one of 3 special characters that do require special handling when used in ODBC connection strings, and it seems it does not work correctly.

Yes, this mechanism will work even when migrating AGENTs ERA 6.5 to ESMC 7.2. There are even migration variants where new server is installed on the same hostname/IP, which would be completely transparent for connecting devices.

Please double check that there is no configuration policy in your console that would do this. Also check that there is no remote deployment task, or any other deployment mechanisms actively used, as installation repair is another method how AGENT might be redirected.

I think it might be one of following problems: Password is not escaped correctly when provided to installer script (or maybe even there are special characters that broke our installer) - I guess password contains special characters? Version of MySQL -> MySQL 8 uses new authentication mechanisms by default and authentication would work only with ODBC 8 drivers. Wrong password for user root@localhost -> it might happen that you have multiple root users, for example root@127.0.0.1 or root@% and in case of local command line client, different user might have been used...

Also note that during installation attempts, also more detailed log is present in: /var/log/eset/RemoteAdministrator/EraServerInstaller.log which might help to locate source of the problem. Regarding mentioned error, it indeed points that there is something wrong with driver name - but from provided data is seem to be correct, i.e. you are referencing proper ODBC driver name. I would recommend to check that driver library referenced in ODBC entry is actually accessible. Also I would propose to switch SELInux to permissive mode, just to be sure it is not just a problem with SELinux