MartinK

Could you please check installation log /var/log/install.log for relevant entries mentioning "Eca"? It is hard to guess what could be problem, might be problem with minimal requirements, wrong configuration, etc...

As @Marcos mentioned, second (GET) attempt provides credentials and that is why it succeeds. Initial HEAD request is used as "authentication probe" and is configured so that even non-200 response won't invalidate cache, as would by default happen with GET request with 401 response.

Agent-to-ESMC goes by default to port 2222. Port 2223 is used for Console and API connections (also used when using "Server assisted" installation).

Actually I meant Agent-to-ESMC, which is using TLS+HTTP2. It is now possible to route this connection through proxies and that is why our own ERA Proxy was discontinued. But even it is forwarded through proxy, there is no caching possible -> encrypted connections are just forwarded so it can be used as a network router for our communication, even when it is is actually internal, i.e. it does not leaves company network.

Could you also provide version of original ERA Agent that remained installed? We have prepared cleanups only for specific official release, so maybe this version was not covered. Also what happens when you try to uninstall this "remnants"?

We are using standard apache utility named htcacheclean. In latest appliances it is started as a system service, regularly and it is using default configuration for now, which means cache should not be larger than 10GB and should not contain more than 12000 files after cleanup execution. It is a precaution to not cache something unexpected for too long. ESET services that are expected to provide cached content are using specific values, ranging from 10sec to days, depending on type of provided data. We do plan to increase this value in the future but I do not recall any ESET installer to be larger than 200MB, could you provide more details? ESMC is using TLS+HTTP for Agent-to-Serve communication, which can be forwarded through proxy. In order for this to work, only change is that target hostname and target port has to be explicitly enabled in proxy configuration. Also changes are required for EDTD to work properly in case you are using it (it is extra paid service so you would know). In case you are interrested in diagnostic of caching performance, I would recommend to extend configuration with logging of cache results. For this purpose, official apache documentation recommend somethinkg like this: CustomLog "cached-requests.log" common env=cache-hit CustomLog "uncached-requests.log" common env=cache-miss CustomLog "revalidated-requests.log" common env=cache-revalidate CustomLog "invalidated-requests.log" common env=cache-invalidate Please see relevant apache documentation for more details and also be aware that most ESET resources will be in "revalidated" category, not in "cached" as most of the requires are configured in a way that revalidation of data is required (i.e. fast check will be made whether cached data has not changed in the meantime).

Thanks for pointing this out -> I think this is the core problem and I have to ask whether is is supposed to work this way. Technically in ECA you can actually set only HTTP proxy for "ESET services" and that is why global proxy is not overridden. This also means that if such proxy configuration was used before migration to ECA, it will remain because policy from ECA won't override it.

I think response 301 would be visible in case clients were using HTTP headers like "If-Match" or "If-Modified-Since" which is not case. Also be aware there are resources (especially update modules for endpoints) are configured in way that re-validation is required. This means that even when file is cached by proxy, HEAD call is made to ESET servers just to verify there has been no change in file. Also endpoint will be performing HEAD request with "no-cache" headers to verify authentication requirements -> those requests are automatically forwarded to ESET infrastructure.

Please verify that AGENT you installed has version 7.0.577.0. Otherwise it is a known issue and is should resolve after upgrade.

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?

Remote deployment tool is supported, it should detect .dat file and use it to deploy also on remote clients, but make sure you are using latest version of deployment tool.

Even with .dat file prepared side-by-side to installer I think there will be still call to internet, but just to download metadata for installer, required to connecto to ECA. All product installers (MSI files) should be extracted from provided cache file, which is supposed to reduce overall download.

Could you please provide error messages from AGENT's trace logs? I cannot recall any changes in HTTP proxy configuration nor in AGENT applications itself. Please in the meantime verify that configuration policy with HTTP proxy parameter for remote clients is correct -> there has been change in design of proxy settings. Regarding error "Failed to synchronize package repository" it means that AGENT is not able to download repository metadata, which is set of files (few MB at most) and there has been not much reports that this fails as most issues are related to downloading installers itself which are almost ~150MB. That is why I think there is something not configured properly, either AGENT's have no access to proxy or repository. Could you check configuration of AGENT from remote device (it can be requested in specific client details view) and verify both mentioned settings (HTTP proxy for ESET services and Repository URL) are configured properly, i.e. reachable for remote client?

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.

Indeed there is definitely something wrong. This client is clearly not configured to connect to ECA -> any chance you have made some policy imports into ECA? Or some local repair of this client? Replication interval seems to be correct, i.e. this client was connected to ECA, but later it changed it's connection hostname.