Mirek S.

I have answer it for my own.
First the hostname is present when you creating a new device for MDM. There is a name for MDM Server.
Second, if You open in web browser this hostname with port 9980/9981 You should have an information that MDM Server is runing on and its correct.
Then You have an informations for creating a new Certificate with point of running MDM Server hostname
You Can close this subject.

Hello,
As a sidenote there was also added option to supress Apple related protection states (as many of our users don't use Apple devices). It's in MDM policy "General" > "Send iOS related application statuses". However as Apple only conforms to CA/Browser _consortium_ it's best practice to conform to these rules as well.
HTH,
M.

Please try this: In the system setup -> Apps -> select the ESET Authenticator app -> Storage -> Clear data.

You can hide this message using a policy for "ESET Mobile Device Connector".
Here disable the Option "Send iOS related application statuses".
Ensure that you assign this policy to the server running the MDM. Also check that the machine is currently talking to the ESMC - according to the screenshot last communication was 13th of january?
 

Hello Mirek,
We need to run Apple Configurator 2 on multiple iPads because they were not purchased through ABM authorized resellers.  This appears to be possible, and supported:
https://support.apple.com/hr-hr/guide/apple-configurator-2/cad99bc2a859/mac
Regards,
Chris

Hello,
Android team is currently investigating this issue with self-signed certificates. If You use self-signed certificates (ESMC generated) please fill ticket with customer care so there is more data regarding this (we will need logs from phone and mdm certificate to speed up the process).
Sorry for inconvenience,
M.

Hello,
Android team is currently investigating this issue with self-signed certificates. If You use self-signed certificates (ESMC generated) please fill ticket with customer care so there is more data regarding this (we will need logs from phone and mdm certificate to speed up the process).
Sorry for inconvenience,
M.

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

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.

We have successfully implemented haproxy in front of ESMC in a test environment.
Our first attempt to run in http mode failed, as we found that ESMC agent does not seem to send back valid HTTP responses which comply to http standards.
But we further found that this is not a problem with what we want to achieve (checking validity of the client cert on the reverse proxy side), as TLS bridging with haproxy also works in TCP mode.
Following is the relevant part of the haproxy config:
frontend esmcAgentFE mode tcp option tcplog bind *:2222 ssl crt /etc/haproxy/ssl/crt/esmcServer.pem verify required ca-file /etc/haproxy/ssl/ca/esmcCA.pem default_backend esmcAgentBE backend esmcAgentBE mode tcp default-server ssl default-server ca-file /etc/haproxy/ssl/ca/esmcCA.pem default-server crt /etc/haproxy/ssl/crt/esmcAgent.pem server default esmc.mydomain.com:2222 Cheers

@segFault
As ESET Business Account is used as "identity provider" and "authentication service" you can enable 2FA within business account settings. Back-end architecture of ESET Cloud Administrator is designed in a way, that it´s fully backed-up and redundant. Meaning that despite you set a location you belong to, unless the entire data-center goes down, service will be available). I will check, whether a cross-data-center backup is planned.

I think so.
To get sure I did the last change yesterday evening and had a look at the results today. Group was still empty. Then I changed from "regex" to "has prefix" and 10 minutes later I saw the first computer appearing in the group.

That's a smart kid you have , it's quite a good thing , he is cheating your security measures , another version of you.
You can lock the software with an AppLocker , but that won't prevent him from booting to safe mode again and remove it , you can close your bootloader/recovery , so he cannot do hard reset.

After leaving eset for the last 3  plus years  its'  its glad to be back.I used another top brand name security software,and after installing the lastest version,and after about a week of the trial version,I was excited to purchased eset,upon install I noticed a difference the way my machine acted.Very Smooth and Stable,I didn't  know security software could make that big of a difference.What a difference ESET made on my machine.I can't speak for everyone,but I know eset security did for me,So For So Good, Thank You

It appears that a number of Eset users employ license "crackers." It also appears that a number of Eset forum participants feel that the most widely used , the KMS software family of crackers, are safe. As noted in this recent analysis of KMS based software by AVLabs in Poland, they are definitely not safe to use.
 
KMSAuto and KMSpico are the most commonly installed hacktool on computers in Poland
https://translate.google.com/translate?hl=en&sl=pl&u=https://avlab.pl/&prev=search&pto=aue
Note: This article was posted in the Polish language. Hence the use of Google's Translator.

I turned on startup scan in normal mode and enabled AppVerifier in safe mode. When I returned to normal mode, ESET did not load into the system, and the issue cannot be triggered. I tried manually open ESET Security through Start Menu, but nothing happened after I clicked the icon.

Hello guys,
Okay, I removed (from safe mode) EEA with esetuninstaller.exe, then reinstalled my usual 5.0.2272.7 x64 on my Win7.
Then I go to > advanced configuration > computer > HIPS > [uncheck] Selfdefense, and I performed a virus database update, then I rebooted.
With Selfdefense OFF, I tried to perform a procdump and it freezed Windows, no dump file was writen to disk, and I just totally lost control over operating system.
I tried multiple times to generate a dump with selfdefense OFF, but it just totally freeze win7 (with / without "-e 1", "-ma", "32/64 procdump.exe", etc.)
So I decided to enable again Selfdefense and start the command "procdump.exe -ma -s 10 -n 720 ekrn.exe" to have one dump every 10 seconds (because with selfdefense ON, I can't use "-e 1" unfortunatly).
I also runned "process monitor", and wait the issue to reproduce.
I feel that when the exception occurs, EEA is performing one of the startup scan because I can see the eset icon turning into taskbar, and overlib speak about startup scan, not virus database update.
Could it be related to memory ?
This startup task is eating a lot or ram (1.7 GB!), maybe there is one kind of infinite loop here.
About dump, the bigger eea was using memory, the less dump file I could generate (See screenshot, "Error writing dump file: 0x8007000D").
Another information, once the ekrn.exe engine is broken, disabling AV from GUI is useless, but I can have internet access again with the following settings modifications:
USELESS = advanced configuration > internet & mail > protection of web access > HTTP & HTTPS > [Uncheck] Activate control
USELESS = advanced configuration > internet & mail > protocol filtering > [Uncheck] Activate content filtering
FIXED = advanced configuration > internet & mail > protocol filtering > [Uncheck] System integration
So finally, I was able to trigger the bug and have a 1.3 GB dump before and a 1.9 GB after freeze, let's hope it will help
I also have one whole 4GB logfile from ProcessMonitor.
Please find my complete debug session files (14GB) at the following URL (it's one ultra 1GB 7z file with 512MB dictionnary RAM compression):
hxxp://tmp.zool.fr/tmp/eset/20200713_NoOutgoingPacket.7z
Thanks !

Thanks for your fast reactions. I really appreciate it.
The situation is a bit complicated, but try to explain:
We are a large, heterogeneous research institute. There is no central ActiveDirectory that manages all clients. We have Windows, MacOS and various Linux clients.
We are currently preparing to switch from ERAC 5 to ESMC 7, finally.
We have clients that only have access to our internal network;
clients that are allowed to access the Intranet and the Internet;
and clients that are operated outside our network for a long time (e.g. external research locations).
Many employees are only with us for a few months and also bring their private devices with them.
As long as they work with us, they get an institute account and are obliged to use our ESET Antivir solution.
However, if these employees leave, we want to prevent them from continuing to benefit from our ESET license. With protecting the update-server with authentication; when their account expires with their departure, they can no longer access our update mirror server.
So far with ERAC 5, we have had 2 update servers. Once the ERAC as a mirror-server itself via http without password protection in the internal network.
And in addition, precisely because many of our devices are operated outside of our network for a longer time, an https mirror with password protection. Each user has their own login data, which become invalid when the user leaves our institute.
With the switch to ESMC 7, the idea is now to provide a single update mirror server in the DMZ. All clients within our network (whether they have an internet connection or are only allowed to use local resources) can receive their updates from this update mirror without a password based on internal IP addresses.
Clients who are temporarily or a longer time outside the internal network should use a password to access their ESET updates as long as the user has an activated institute account. This password is only known by the user, so they must enter it into the ESET antivir settings on their client.
Clients, who leave our institute and therefore have no valid account anymore, should of course no longer be able to use our ESET antivir infrastructure.
So thats why almost every client setting should therefore be set by a server-side Policy, except for the update setting where user name and password are stored.
This is exactly what is currently not possible with Windows clients. But it is possible with MacOS / Linux Client Policies, so it would be nice if this were possible with Windows Client Policies also.

Since figuring out the root cause of the issue will require further troubleshooting and also more information will be required, I would strongly recommend opening a ticket with your local ESET support to ensure that the case is tracked and dealt with properly.

Please use "MS SQL Server" db instead of "MS SQL Server via Windows authentication".

Got it, Turns out I had made the change already. My memory just isn't what it used to be.
Getting old isn't fun at all, but it beats the alternative.
Thanks to both of you for your help.

So far, so good. Will post again if it starts acting up again.

I use Ubuntu 20.04 LTS + MySQL 8.0.20 + ODBC from recommended link https://dev.mysql.com/downloads/connector/odbc/5.2.html - but after selecting Ubuntu Linux 20.04 there is only one version - mysql-connector-odbc_8.0.20-1ubuntu20.04_amd64.deb
In april I've upgraded Ubuntu from 18.04 LTS to 20.04 LTS. Works perfectly with EMCS 7.1.503.0. Couple days ago I wanted to upgrade EMCS to 7.2.2233.0 via WebConsole. But upgrade was not sucessfull. From logs I read that I have no SUPER right for DB user. I've given this right but EMCS just not worked. I can't repeat update via WebConsole. I downloaded EMCS installer from Web, but instalation failed - with error sth like "corupted DB". I deleted DB and restored from backup and once again - run installer. Instalation was successfull, but EMCS service failed. Port 2222 was not open, few seconds after start eraserver - server crashed.
After many different tries, I wrote to polish Eset support (Dagma). I've got simple answer (without any log analysis) - something like "you use unsupported Ubuntu version. Try on supported version and contact us if it will not work".
Today I do clean install EMCS (without certs create). Install was successfull but... EMCS stil crashes few seconds after start. I can send you full logs and crashdumps, but I prefer not to publish logs on public forum.
Sorry for my English. Regards
deg
EDIT:
Oups! I have deleted some earlier logs (before clean install), but I send these logs to polish Eset support - ticket number #0675574.

The certificate for the web site has been revoked: https://www.ssllabs.com/ssltest/analyze.html?d=clik.tradingacademy.com
Contact the web site administrator of this status. Or contact the concern by whatever means and inform them of this status.
Note: regardless of Eset use or not, any browser will also reject the connection to this web site due to it's revoked certificate status.
 

Hello,
Device ID in MDM database is pseudorandom due to google privacy policy (unless device is enrolled in Device Owner mode). To remove device from MDM run stop managing task wait a few minutes (due to replication), EESA should be uninstalled if device still has connectivity. It should be safe then to remove device from ESMC console. Devices which receive stop managing task have DeEnrollmentFlag set to 1 in Device table (I believe since 7.0 version) if there's a quirk and it's not removed automatically.
HTH,
M.