MartinK

In case there is a firewall, you have to enable port 443 (standard HTTPs) or possibly other simillar port, the same you are using locally.
Short summary of ports in default:
2222 is ports used for AGENT->ESET PROTET communication and should be generally opened from network where AGENTs are installed 2223 is port used by Apache Tomcat to communicate with it's backend and also it is used by installers to communicate with it. In case you are not using so called "Server assisted" mode of installers, there is no need to open this oper to outside networks 443/8443 is default port used to connect to console using standard web browser. This port has to be accessible to devices where browser/console users will be connecting from. Specific value os this port might depend on environment and Apache Tomcat configuration.

Just to let you know, problem was indeed triggered by localized Windows operating system, i.e. operating systems where certain status messages provided by system itself contained non-ASCII characters.
Unfortunately problematic helper tool UpdaterService.exe is part of already installed version 7.2.1266.0 and therefore proper solution was not possible and upgrade from this specific version to any new version will report this kind of failure even when upgrade will be successfully. Also it has been confirmed that upgrade from version 8.0 is not affected, so there should be no such problem with future upgrades.

Hi Thomas, 
My solution is the following:
 
1.:  - I created a dynamic group for collect the computers with error message "Restart required" :

 
2.:  - Then I defined a CRON triggered task for send a pop-up window message into the affected computers:
"Hello Collegue, please restart your computer as soon as possible because an ESET software update...bla..bla" or something like this
You can configure the CRON for example launch the message hourly, every 10 minutes or as you want  
 
It works pretty fine
 

Just a note. We have just released a hotfix version of ESET Protect Webconsole, that should address the issue with login, when username / password contains a special characters. You can upgrade the console to the current version by running a component upgrade task on your ESET PROTECT server machine. IT will update the webconsole to the version 8.0.175.0 which should resolve those issues. 

Actually enabling advanced security has not impact on certificate validations - it just forces console to generate more secure certificates, but original ones would still work.
But what changes with enabling advanced security is that older TLS protocols (If I recall correctly, older than TLS 1.2) are disabled for AGENT connections, and also older and no-longer-safe cipher suites are disabled, which means that only devices with support for latest protocol versions would connection. Recent versions of AGENT do have this support, as they no longer rely on cryptographic primitives provided by operating system, but in case TLS introspection is used in between AGENT and SERVER, it might be blocked in case it does not support any of safe algorithm.
Regarding analysis, this seems to be network or TLS related, so I would recommend to analyze network communication using tools like wireshark. It is possible that problem is between TLS introspection component and SERVER, and not between AGENT and TLS component, so proper place for capturing of traffic will be required.

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.

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.  

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

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.

Indeed as of now, it is proper workaround fr this issue. This FQDN value will be used as default for installers, used in case override is not provided explicitly.

For me it worked like a charm.
Clicked the desired detection and selected Create exclusion from the menu:

This excluded the detection name from detection:

Hello guys,
I think I found the problem and it really is not technical, the problem is with the translation into Spanish from Latin America. Let me show you:
In the latin american user guide, you can see this instructions:

Highlighted in yellow you can see that it indicates that for Linux MySQL version 8, the parameter log_bin_trust_function_creators = 1 must be added or modified. But it is indicated only for Linux environments. In the English manual this option is not conditioned to Linux:

As I was working in a Windows environment, I chose not to make this modification, because the manual indicated that it should only be done in a Linux environment. Just to discard I decided to make the change and everything works correctly.
Thank you very much for your collaboration and if you can please change the manual (Latin America Spanish) in this section as it may cause confusion.
Regards.

Requirement to target silent/mass deployment to macOS devices should be targeted in next major release.

Ok, Solution found: LC_ALL was not set. "export LC_ALL=en_US.UTF-8" did the trick.
 
Regards
 
Daniel
 

If I recall correctly, only login&logout audit messages are actually exported, i.e. there is probably no way how to export other audit messages.
There has been issue in one of previous releases (probably 7.1) where wrong delimiter was used in LEEF format, which caused issues when parsing messages - this is probably why they were not visible in QRadar as they were supposed to be.

Changing certificate to original in ESMC' settings should be enough:

When you click "Open certificate list", you should be able to select original certificate, the one as shown in your previous screenshots. Just be aware that change will require restart of ESMC service.

Any chance changing "legacy" filter in packages table helps? Also I would recommend to check ESMC's trace.log for possible synchronization (network) or database related errors. It is possible that repository synchronization is failing and list is not updated correctly.

Thanks for letting us know. First part is considered as an issue and should be targeted. Second part will be discussed as an possible improvements, which seems to be legit.

Thanks for letting us know. First part is considered as an issue and should be targeted. Second part will be discussed as an possible improvements, which seems to be legit.

TLS connection is actually initiated by ODBC driver installed in system, so it is not in ESMC control. Could you please check what ODBC driver is actually used by ESMC and possibly install latest version. My best guess is that older version is used, which has no support for TLS 1.2. Also it seems that SQL Server 2014 in latest version you are using is supposed to fully support TLS 1.2: just for information, with recent versions we are installing SQL Server 2019 + all-in-one installer do even support upgrade of database server is supported by operating system, but ODBC driver is not installed nor upgraded.
In order to check or change ODBC driver used by ESMC, please check DB connection string file as described in documentation. In referenced article, relevant parameter is Driver=SQL Server, i.e. in example, very old ODBC driver is used. In case it is also in your case, I would recommend to upgrade to Microsoft ODBC Driver 17 for SQL Server. It will also require to modify ESMC DB connection string, probably to Driver=ODBC Driver 17 for SQL Server, where exact name can be verified in ODBC Data Source control panel:

As AGENT->ESMC protocol currently used gRPC on application layer (not guaranteed to the future), there are many small projects and proxies that can be used to routing, but in case of security, most reliable solution might be standard TLS termination and forwarding of requests on TCP layer, i.e. without interpreting data and requests itself. This is supported by most of the commonly used proxies ad mentioned previously. It would just require some basic "magic" with certificates. In this configuration, proxy should be just "repacking" TCP traffic from one TLS channel to another, instead of interpreting it + it is possible to configure proxies to be transparent for AGENTs. This kind of configuration is very often used for load balancing.
Your case would be probably best matched by something like TLS pass-through with additional client certificate checks, but it is probably not supported by common proxies, I think it not possible to validate client certificate before connection to backend service (ESMC in this case) is opened, so it would somehow reduce security benefits.

ESMC Agent are using mutually authenticated TLS (both endpoints do have to present with it's certificate), which is protecting underlying HTTP2 requests, so technically it is HTTP2 over TLS.

Indeed ESMC 7.2 introduced mechanisms for throttling connections and received data -> its purpose is to limit load and prevent service exhaustion for temporary peaks, mostly detected during work time hours start. This change was definitely not supposed to increase number of pending logs, but during development, it was discovered that counters were previously not accurate, which might explain increase you are seeing.
Regarding performance, most crucial is performance of database, which is connected to performance of underlying storage. I would recommend to check whether storage performance is not hitting its limits. In case of cloud, I would recommend to check IOPS limits on storage and database.
Could you also provide number of managed / actively connected endpoints just for statistical purpose? We are interested in such numbers as it would enable us to adapt mentioned settings.

There has been a few changes implemented in DNS servers that should possibly help with this case, as problematic data center should be used only as a fallback for connections from Germany.