MartinK

Got mine working yesterday. Do you have Microsoft MFA enabled? If so, then you need to create an App Password for that user, and you use that App Password as your authentication password.
Details below work for me.

Actually you have to use different tasks to upgrade applications:
Components upgrade task is required to upgrade ESMC Agents Software installation task is required for upgrade of other ESET applications

Please provide list of installer parameters you are using to deploy AGENT (only parameter names, no need for passwords or other sensitive details). From log it seems you are performing so called server-assisted installation, but probably with wrong hostname:port configuration, resulting in communication failure.
Also once ESMC is installed, you might use also live installer created in console to deploy AGENT, it has no parameters so it would be much simpler.

For those of you in the same situation, I first had to install SP3 for SQL Server 2008 R2 Express because you can't directly upgrade to SQL Server 2017 Express unless you are running SP3.  I was running SP2.  Once this was done, I upgraded to SQL Server 2017 Express by using the custom install option.  I then opened ESMC and went to Help->About.  The DB version is now showing Microsoft SQL Server 2017 (RTM) Express Edition (64-bit) 14.0.1000.169.  I then went to Help->Upgrade Product and a new client task was created.  After a few minutes, I was kicked out of ESMC and I could not log back in.  A few minutes later, the login page wouldn't even come up, but after some more time, it finally came up and I was able to log back in.  ESMC is now showing it is v7.1717.0 and the Web Console is at v7.1.393.0.  The last thing I did was install SQL Server Management Studio (SSMS) on my server so I could manage the DB a little easier.
https://docs.microsoft.com/en-us/sql/database-engine/install-windows/supported-version-and-edition-upgrades-2017?view=sql-server-ver15
https://docs.microsoft.com/en-us/sql/ssms/download-sql-server-management-studio-ssms?view=sql-server-ver15

Just for clarification for others in case they encounter this issue: unknown state indicates that for specific application version ESMC is not yet aware of it's state. This normally happens when new version of application is seen for the first time and it should be resolved automatically in no more than 1 hour.

I think this behavior has been already reported and probably fixed in the meantime. Maybe @Marcos will know more details of whether module responsible for scanning network has been updated in the meantime. It is also possible that update was canceled which might explain why only specific devices were affected.

Just for clarification for others in case they encounter this issue: unknown state indicates that for specific application version ESMC is not yet aware of it's state. This normally happens when new version of application is seen for the first time and it should be resolved automatically in no more than 1 hour.

I would recommend to start by checking whether ESMC Agent installed on client machine is actually connecting to ESMC. For this purpose please follow troubleshooting part of documentation - especially status.html log present on client machine might be helpful in this case.
In case ESMC Agent will be connecting to ESMC, most probable issue is that is is using different name in ESMC or is located in different group, which prevented ESMC to remove "dead" duplicate that is rendered as unmanaged.
In case AGENT is not connecting to ESMC, it is crucial to resolve connectivity issues as described in referenced documentation.

Just for verification: is your license intended to activate ESET Endpoint Security? Asking because this would probably happen if you try to activate it with license for different product, i.e. ESET Endpoint Antivirus or possible other.

When installing ESMC, following credentials are required:
password for to-be-created ESMC user "Administrator" ( --server-root-password) credentials of DB administrator, i.e. DB user that has permissions to create database and create new user if required ( --db-admin-username , --db-admin-password ) DB user to be used by ESMC service to connect to database ( --db-user-username , --db-user-password ). This user can be the same as administrator, but I would not recommend that. In case provided user does not exists, it should be automatically created using DB administrator account -> created user will be granted permissions required for ESMC operations and it will be limited to ESMC database.

I would recommend to start by checking whether ESMC Agent installed on client machine is actually connecting to ESMC. For this purpose please follow troubleshooting part of documentation - especially status.html log present on client machine might be helpful in this case.
In case ESMC Agent will be connecting to ESMC, most probable issue is that is is using different name in ESMC or is located in different group, which prevented ESMC to remove "dead" duplicate that is rendered as unmanaged.
In case AGENT is not connecting to ESMC, it is crucial to resolve connectivity issues as described in referenced documentation.

I would recommend to start by checking whether ESMC Agent installed on client machine is actually connecting to ESMC. For this purpose please follow troubleshooting part of documentation - especially status.html log present on client machine might be helpful in this case.
In case ESMC Agent will be connecting to ESMC, most probable issue is that is is using different name in ESMC or is located in different group, which prevented ESMC to remove "dead" duplicate that is rendered as unmanaged.
In case AGENT is not connecting to ESMC, it is crucial to resolve connectivity issues as described in referenced documentation.

I would have to verify by my self to be sure, but reason is probably that negation of specific condition is not very clear and it can be easily misunderstood. For example condition Installed software . Application version doesn't contain 7.1.2053.0 will be probably always true, as there will be also ESMC Agent with different version in list of installed applications. In case of version it makes no sense to use this kind of expression.
My recommendation is to use positive conditions inside group definition, and instead negate result, i.e using NAND group type with following filters:
Installed software . Application name = (equal) ESET Endpoint Antivirus Installed software . Application version = (equal) 7.1.2053.0  

Is there any known method you are already using to fetch FQDN on those machines? For example some command line tool, shell command, etc.? Does output of any of following command:
hostname hostname -f scutil --get ComputerName scutil --get HostName scutil --get LocalHostName sysctl -a mention value that could be possibly used as FQDN?
We have already seen machines that were configured in a way that they were not aware of their's FQDN, it was available only on DNS servers, but that is problem for ESMC Agent which requires data to be available locally.

Value of kern.hostname should be actually used by AGENT so setting it should resolve problem. There is definitely no need to reinstall AGENT -> hostname is not fetched very often, so easiest would be to restart AGENT's service. It can be done using following commands in root terminal:
cd "/Applications/ESET Remote Administrator Agent.app" ./Contents/Scripts/restart_agent.sh  

He has asked to cancel his account here. But yes, it's not normal that a user of a trial license would request a response within 1-2 hours 24x7 that is granted to VIP customers at an extra fee. Moreover, the problems with LiveGrid authentication suggesting an invalid username/password being used was highly suspicious too.

As it is Sunday (most ESET staff is off)...and your OP was just 3 hours ago, why don't you try being realistic and reasonable with your expectations.
 

Could you please provide logs located in directory %temp%\eset\ (i.e. in temporary directory of user that executed installer)? This specific error means that it was not possible to find installer matching requirements. Most commonly when in case:
version of product is no longer available (if version was explicitly requested when configuring installer) operating system is not supported by selected product (desktop vs. server products) ESET repository servers (repository.eset.com) are not available. Access might be blocked by other security-related software, or HTTP proxy configuration might be required.

Certificate that is considered by ESET products as untrusted, i.e. injected into communication has following identifiers inside:
IP Address=fe80:0000:0000:0000:...:2a5a IP Address=192.....204 DNS Name=localhost DNS Name=G....net.local which might help you identify source.
Otherwise certificate contains no other details, it actually like like default certificate that is generated for ESMC Webconsole, but it makes no sense to be injected into communication. Could you verify this certificate is used by your ESMC console for Apache Tomcat connections (I have made some redaction of data present in certificate)?
Also as you mentioned, MAC addresses from communication with ESET licensing server (IP=13.91.57.145) indicates that next device is Sophos, but it does not mean it is source of this injected certificate.

Today we've released a fixed version of the Antivirus and antispyware module 1552.3 which addresses cleaning issues on Mac. Could you please check if PUAs are now cleaned properly?

Any chance it resolved itself automatically after a time? We are currently experiencing issues with license synchronization, which is targeted by release that is rolling out this week.

There has been support for cloning implemented in ESMC, which means this scenario should be handled automatically if properly configured, without executing mentioned task.
Once machine was cloned, new Cloning Question for ESMC administrator should have been created -> until it will be resolved, cloned devices won't be able to communicate with ESMC and thus not able to reset itself. There is possibility to resolve it in a way that every other clone of specific device will automatically results in creation of new devices, as if reset cloned task was executed. I would recommend to check whether there are any cloning questions available -> they should be accessible through client details of "master image" or in status overview in ESMC console.

Problem seems to be in MySQL ODBC driver used. Unfortunately ESMC 7.0 does not support latest versions as there is some bug in driver itself. It was supposed to be fixed in ODBC driver 8.0.16 released recently but seems there might be some another issue.
I would recommend to check documentation where latest supported version of MySQL ODBC driver is mentioned. If I recall correctly, latest working version is 5.3.10.

I would recommend to check file:
%PROGRAMDATA%\ESET\RemoteAdministrator\Server\EraServerApplicationData\Configuration\startupconfiguration.ini which contains connection string as used by ESMC. Please make sure you create backup before doing modifications. Resulting connection string is passed to SQLServer ODBC driver and thus all parameters supported by driver should be working. Also be careful with using reserved characters as are @,{,},... as it might require special escaping to work properly.
Also be aware that changes in this file might break upgrade of ESMC in the future, and even if upgrade is successful, it might replace this file with new one, without custom changes you made.

Unfortunately remote deployment task has a glitch that it shows successful installation even in case installation actually failed. This is issue of last phase of installation, so it means ESMC is able to connect to this device, but either download of AGENT installer or installation itself fails. Most probable cause is download, especially in case device has limited access to internet or ESMC is configured to use HTTP proxy.
I would recommend to create Windows live installer in console (it is bat script) and try to execute it manually on device. It will behave exactly as it executed remotely, but local execution might help diagnose the issue.