MartinK

That is correct column for this scenario. Remote host shows IP address as seen by ESMC, which is suitable for remote clients, until they are not hidden behind NAT router or load balancer which would result in multiple devices with the same IP address.
IP addresses shown in other column are based on local state on AGENT, where IP address of interface with highest priority should be shown - but it might have no relation to interface that was actually used to connect to ESMC.

Hope that helps. Crucial parameters are:
sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2" ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA" where you can limit not only TLS protocol but also list of supported cipher suites, even when we have already enabled only those most secure and considered as secure by various analysis tools.

Unfortunately this is not configurable via UI. It i actually part of Apache Tomcat configuration distributed with ESMC. Please check following KB3724 but just search for TLSv1 and you will understand what to search for in server.xml configuration file. There is no need to follow this KB as it is unrelated.
Regarding question why it TLS1 enabled by default - it is due to backward compatibility as ERA6 clients were using TLS layer provided by system itself, and we do still support older systems (Windows XP as an example, but also older Linux and macOS) which do not support TLS 1.2.

Unfortunately I am al so not sure how it was meant. We are officially declaring maximal number of managed clients to 10000 when using MySQL database, but it is not related to number of actually connecting clients, but rather limit is amount of data. ESMC installed over MySQL might have performance issues with processing larger amount of data and rendering larger datasets. As an result rendering of specific reports (threats for example) might be much slower, but in "clean" network even much larger environments can be managed with MySQL-based ESMC installation.
Persistent connections as introduced in ESMC should actually significantly reduce load of ESMC server, especially in "dormant" state when no changes are made in management console. If properly configured on recommended HW, ESMC should handle hundreds of clients per second.

If I recall correctly there was an issue with presets using incorrect values. I think "User Group Name" should be set to name but I am not sure it will be able to rename existing groups -> have you tried to change this value and erase at least some of the groups, just to verify that even newly added groups are still named wrongly?

This is the most probable reason. ECA does not enable user to create policy with connection hostname, but policy imported from ESMC will retain this setting. So in case you imported policy that had some connection host specified, ECA agents will start to us it instead of their original ECA hostname. If this is the case, only solution is to unassigned/remove such policy (unfortunately you won't be able to see which one it is as this setting are hidden in ECA console) and repair AGENT by re-deployment of installer.
Regarding proxy, I am not sure whether I do understand scenario, but in case you used HTTP proxy for ESMC, and you do not with to use this proxy for ECA, you have to create new policy in ECA, where you explicitly disable use of HTTP proxy. In case you do not do that, AGENTs will be still using previous settings, i.e. they won't revert to settings used before policy was applied. This can be fore example done by creating policy:

where crutial parts are highlighted. Not visible "Proxy configuration type" should be set to Global proxy.

Any chance those two missing devices are "muted"? Seems that dashboard reports them as problematic even when muted, which I consider a bug.

For future reference -> this is actually bug in ESMC itself and should be resolved for upcoming releases. In case there would be no issue, weak ciphers would be disabled in so called "Advanced security" mode which is available in ESMC's configuration. Those weak ciphers are available only for older ERA Agents connecting from even older operating systems (Windows XP, ...) where no secure algorithms were available in system.

Just guessing, but only ESMC functionality actually using SSH is "Remote deployment task", could you verify it is not scheduled to be executed regularly?

Yes please verify that hostname of macOS machine is correctly set. Otherwise AGENT won't be able to report FQDN name to ESMC, and thus ESMC won't be able to pair device with FQDN entries in domain.
Recently we were solving similar issue as support ticket, and customer used command:
sudo scutil --set HostName devicename.example.com to correctly set FQDN name on macOS device.

Yes please verify that hostname of macOS machine is correctly set. Otherwise AGENT won't be able to report FQDN name to ESMC, and thus ESMC won't be able to pair device with FQDN entries in domain.
Recently we were solving similar issue as support ticket, and customer used command:
sudo scutil --set HostName devicename.example.com to correctly set FQDN name on macOS device.

Yes, it is possible, but you have to be careful as it might result in inability of AGENT to connect even to their original ESMC.
Roughly you have to:
choose new ESMC (i. e. one of existing, or install completely new ESMC) -> I will reference it as "primary ESMC" ensure that ESMC's peer certificate (as set in server settings) contains all required hostnames (or wildcard *), so that AGENTs can connect using various hostnames/IP address. export CA certificate from "primary ESMC". It has to be CA certificate that has been used to sign certificate used for incoming connections, set in server settings. import CA certificate from previous steps into all original ESMC instances. export CA certificates from all original ESMC instances and import them into "master ESMC".  in this moment, all connecting AGENTs should have all 6 CA certificates (5 original + 1 from new ESMC), which means that they can connect to master ESMC, as they will trust it's certificate. This works also other way around -> master ESMC will trust all original AGENT certificates, which means it will accept connections of AGENTs from all previous instances. In each original ESMC instance, create new configuration policy for "ESET Management Agent" and specify servers to connect to in a way that list of hostnames is used, where first in list is hostname of master ESMC, and second is hostname of original server. This is just to be sure that in case AGENT cannot reach new hostname, it will be still connecting to original ESMC. In case hostname will be the same for all AGENTs, you can simplify process by export/import capability. Policies should be assigned to all clients. From this moment, AGENTs should start connecting to master ESMC. You could optionally create policy for "ESET Management Agent" which changes list of server to connect to and AGENT peer certificate so those available in master ESMC, so all remnants of original ESMC servers is removed.

Unfortunately it was lost during re-design, but it was already re-added for new versions. It should be still possible to create custom report for fetching this client detail.

Number as you see in License management view is provided by ESET licensing servers, i.e. should be more precise. In oppose to that, ESMC reports shows only devices that are managed by ESMC, or more precise are reporting license usage to ESMC.
In you case, there are few possibilities:
there might be devices that are not managed by ESMC, but are activated using license there has been hardware changes on clients, or clients were reinstalled, which resulted in duplication on license servers. In both cases I would recommend to visit ESET licensing portals (EBA or ELA) and check list of activated devices as listed there. In case of duplicates, it should be clear from "seat name". This portal can be also used to manually deactivate or remove device that is no longer active.

I think there are two possibilities (but had not confirmed it is actually enabled):
configure notification over this dynamic group. Unfortunately you will be receiving notification without list, and most probably for each device separately. use scheduled reports. It should be possible to prepare report which shows devices in specific group (or maybe dynamic groups can be completely bypassed here). Once reports is prepared, it is possible to schedule it to be sent to email, and there should be possibility to not send empty data.

Problem is that group as you defined it will be matching devices, where at least one devices has capacity less than 1GB -> so for example devices with connected USB key or even devices with CD/DVD ROM, which mostly reports capacity 0MB.
I would recommend to add another condition, either explicitly specifying id of storage, or possibly requiring that reported capacity is >0. For example:

where only one of additional conditions should be required, byt it depends on your environment. I would recommend to use "Storage Id", especially in case you are interested only in system disks and devices are using default "C:".

You did it! Thanks.
Using custom headers, I am able to specify who gets my reply message Wednesday morning.
Here is the report:

 
And the group that identifies the computers in need of attention:

 
RMM, I don't need no stinking RMM, I have ESMC!
 

I think there are two possibilities (but had not confirmed it is actually enabled):
configure notification over this dynamic group. Unfortunately you will be receiving notification without list, and most probably for each device separately. use scheduled reports. It should be possible to prepare report which shows devices in specific group (or maybe dynamic groups can be completely bypassed here). Once reports is prepared, it is possible to schedule it to be sent to email, and there should be possibility to not send empty data.

Problem is that group as you defined it will be matching devices, where at least one devices has capacity less than 1GB -> so for example devices with connected USB key or even devices with CD/DVD ROM, which mostly reports capacity 0MB.
I would recommend to add another condition, either explicitly specifying id of storage, or possibly requiring that reported capacity is >0. For example:

where only one of additional conditions should be required, byt it depends on your environment. I would recommend to use "Storage Id", especially in case you are interested only in system disks and devices are using default "C:".

Both issues (version check & wrong system) are most probably related to state of ESET Management Agent as installed on machine where ESMC Server is installed. Could you verify that is is actually connecting to new ESMC server? In this migration scenario you had to completely reinstall this AGENT which means there should be two entries of ESMC Server in your console, one representing original server, and one "duplicate" representing new installation.
In order to resolve your issues, you should:
To resolve wrong OS information, ensure there is ESET Management Agent installed on the same machine as migrated ESMC servers ensure it is connecting to ESMC Server verify that AGENT installed on old ESMC Server is no longer connecting to new (migrated) ESMC Server To resolve version check: Once migration is successfully completed, there should be two entries of ESMC Server in your console. Old one should be no longer updating, and version as reported from history is triggering upgrade prompt -> you should erase this entry from console, but be aware that all data tied to this old device will be lost.

This is most probably caused by limits set in your Linux system. Please verify limit for open files in your system, or limits for services in case systemd is used.
In case you are using ESMC Appliance, please check following forum topic:
 

Just to be sure, there are two other settings of MySQL server that has to be changed:
innodb_log_file_size=100M innodb_log_files_in_group=2 Could you verify those too? They can have different values but there are minimal requirements that are larged than default (documentation).

Just to be sure, there are two other settings of MySQL server that has to be changed:
innodb_log_file_size=100M innodb_log_files_in_group=2 Could you verify those too? They can have different values but there are minimal requirements that are larged than default (documentation).

I would try to create new report with following data set configuration:

which should provide you list of devices with public ID of used licenses. It is possible multiple entries per device will be reported in case multiple activated products or multiple licenses are used.

Indeed it seems that Apache HTTP proxy has taken all of the free space. When configuring appliance and proxy is enabled, service used to cleanup cache regularly should be enabled. It uses htcacheclean utility to clean cache directory. From my point of view it seems this service is not working or your proxy is heavily used and all those ~40GB of cached files were downloaded recently.
I would recommend to check status of mentioned service:
service htcacheclean status  
Any chance you enabled apache HTTP later, i.e. not during initial appliance configuration? It would explain why cleanups are not enabled.
In order to resolve this issue, easiest would be to clean proxy cache directory. In case it won't help, we will need some trace logs from ESMC services, so that we can check reason why services are not running. It is possible that actually database (MySQL) has to be restarted as it might also stopped working due to insufficient disk space.