Kamilos

Hello guys,
 
Let me share few findings of our support and dev teams on this with you.
Endpoint 9 started to use EPNS instead of DNS requests to check for license changes. Endpoints 8 and below didn’t report an issue if this check failed.  
When it comes to issues reported on ESET PROTECT Virtual appliance
The issue seems to be the default setting of the following module "reqtimeout_module" which is used/loaded only on VA (this module provides a way to set timeouts and minimum data rates for receiving requests).
 The issue should not be present on the Windows version of the Apache HTTP PROXY because this module is not loaded there.
The workaround could be (1) disabling this module on the VA or (2) setting the appropriate values. We are not sure what is the preferred way and how it might affect other services, as it was not fully tested yet.

To disable limits (i.e. "(2) setting the appropriate values"):
set "RequestReadTimeout header=0 body=0"
in the newly created(in /etc/httpd/conf.d/) configuration file "reqtimeout.conf" with settings mentioned above
and of course the file has to be included in used configuration "IncludeOptional conf.d/reqtimeout.conf" in the "/etc/httpd/conf/httpd.conf"

We are expecting some official solution in the following days.
 
If the customers do not use the Apache HTTP Proxy on VA, enable the Direct Cloud advanced logging, reproduce the issue, collect the logs by ELC and open a ticket for our support teams to check.
  
The configuration option for App status and Notification of "Eset Push Notification Service server cannot be reached" state will be added (P_EESW-8067) The  "Do not remind me again" from EPNS app status doesn't work issue is tracked to be fixed (P_EESW-8048)  
Regards, Peter
 

Couldn't it be that Endpoint is connecting via Apache http proxy to the Internet? If so, you will probably need to configure it as per https://help.eset.com/protect_deploy_va/90/en-US/?enable_apache_http_proxy.html:
1.Create a configuration file reqtimeout.conf:
sudo touch /etc/httpd/conf.d/reqtimeout.conf
2.Open the file in a text editor:
nano /etc/httpd/conf.d/reqtimeout.conf
3.Type this setting into the file:
RequestReadTimeout header=0 body=0
4.Save the changes a close the file:
CTRL+X > type Y > press Enter
5.Open the httpd.conf file:
nano /etc/httpd/conf/httpd.conf
6.Add the following line at the end:
IncludeOptional conf.d/reqtimeout.conf
7.Save the changes a close the file:
CTRL+X > type Y > press Enter
8.Restart the Apache HTTP Proxy service:
systemctl restart httpd

I think there are 2 different categories of customer here.
1st category uses a proxy. (Some have proxy installed on Linux, and some have proxy installed on Windows Server.) 2nd category doesn't use a proxy.  We have ESET Endpoint Security installed on Windows 10 endpoints.  You have to read between the lines in the posts above to tell which customer is in which category.
I'm in the 2nd category, we don't use a proxy, and yet we get the same error message.  (Please go back to my original post to see my screenshots.)  So, our problem is not caused by a proxy.
It seems to me, just based on experience, this seems like a problem with startup order.  When the Windows 10 endpoint boots up, maybe ESET client attempts to contact the management system before the OS has all the networking services up and running.  If this wild guess is correct, it could be solved by changing the startup order, or trying again later long after bootup is complete.
I solved the problem for myself by switching the License Interval Check from Limited to Automatic.  So, if my wild guess is correct, the Limited setting only checks once early in Windows bootup.  So, I switched the setting to Automatic, and the error went away with repeated connection attempts.
I'm well aware this is a wild- guess, I could be completely wrong about the reasons.  But the end result - problem solved by switching to Automatic.

I did 1 and 2, but that "Other" I don't want to, get your devs to create test environment in lab and see for themselves.
eset.zip

Hi
I've got the same problem. In eset endp. av. version 8.1.2037.2 haven't got notification with error. After update few workstations to 9.0.2032.2 and using proxy http server in policy the note appears. Turning off policy with proxy make it disapears.
I have over 150 workstations connectet to Eset Protect so turning off proxy polixy is unacceptable. ESET Management Agent 9.0.1141.0, ESET PROTECT (Server), ver. 9.0 (9.0.2144.0) in virtual appliance

P.S. This notification cannot even be disabled locally.

Hi.
Same problem. I did update few (over 800) endopints to 9.0.2032.2 , most of them have same notification.
ESET PROTECT ver. 9.0.2141.0

Hi
I've got the same problem. In eset endp. av. version 8.1.2037.2 haven't got notification with error. After update few workstations to 9.0.2032.2 and using proxy http server in policy the note appears. Turning off policy with proxy make it disapears.
I have over 150 workstations connectet to Eset Protect so turning off proxy polixy is unacceptable. ESET Management Agent 9.0.1141.0, ESET PROTECT (Server), ver. 9.0 (9.0.2144.0) in virtual appliance

@sdnian
It's not that, I had it on Automatic
@Marcos
I checked /var/log/httpd/access_log and there are lot of entries
[01/Dec/2021:13:38:47 +0100] "CONNECT epns.eset.com:8883 HTTP/1.1" 200 - "-" "-" but no GET entries.
I disabled proxy in policy, after waiting a bit that notification is gone, so now we know that proxy is the culprit here. I didn't have it enabled on ESMC policies, I only changed it in Protect. I can live without it, but we have almost 90 computers in our LAN that use ESET, so I would like to start using proxy.

Hi
I've got the same problem. In eset endp. av. version 8.1.2037.2 haven't got notification with error. After update few workstations to 9.0.2032.2 and using proxy http server in policy the note appears. Turning off policy with proxy make it disapears.
I have over 150 workstations connectet to Eset Protect so turning off proxy polixy is unacceptable. ESET Management Agent 9.0.1141.0, ESET PROTECT (Server), ver. 9.0 (9.0.2144.0) in virtual appliance