rockshox

Apache HTTP Proxy debug logs show that the proxy times out after exactly 60 seconds. See attached logs. Hopefully that will help with determining the problem. Apache_HTTP_Proxy_debug.txt

So, just to test. I stopped the HTTP Apache Proxy service, deleted the cache and started the service. I then successfully pushed the ESET Endpoint Antivirus client to the workstation. I then turned right around and tried pushing the client to another computer in the exact same remote location, and once again received the "GetFile: Error reading HTTP response data (0x4e33)". Clearly something wrong with the Apache HTTP Proxy service on slower links.

I reviewed the Trace logs on the client workstation along with the Apache HTTP Proxy logs, all of which didn't really show any reason for the problem, other than it doesn't work. The trace logs do show the error. I also noticed the error happens within seconds of the task starting the deployment. It's an almost immediate failure before it would even have a chance to really start downloading the installation package. 2018-12-14 21:42:22 Error: CSystemConnectorModule [Thread 6ac]: Software installation failed: GetFile: Error reading HTTP response data (0x4e33) 2018-12-14 21:44:22 Error: CSystemConnectorModule [Thread 6ac]: Software installation failed: GetFile: Error reading HTTP response data (0x4e33) 2018-12-14 21:47:22 Error: CSystemConnectorModule [Thread 6ac]: Software installation failed: GetFile: Error reading HTTP response data (0x4e33) 2018-12-14 21:55:36 Error: CSystemConnectorModule [Thread 6ac]: Software installation failed: GetFile: Error reading HTTP response data (0x4e33) 2018-12-14 22:21:28 Error: CSystemConnectorModule [Thread 6ac]: Software installation failed: GetFile: Error reading HTTP response data (0x4e33) 2018-12-14 22:27:54 Error: CSystemConnectorModule [Thread 6ac]: Software installation failed: GetFile: Error reading HTTP response data (0x4e33) 2018-12-14 22:37:28 Error: CSystemConnectorModule [Thread 6ac]: Software installation failed: GetFile: Error reading HTTP response data (0x4e33) 2018-12-14 22:41:25 Error: CSystemConnectorModule [Thread 6ac]: Software installation failed: GetFile: Error reading HTTP response data (0x4e33) 2018-12-14 23:06:55 Warning: CPushNotificationsModule [Thread 1620]: Failed to configure EPNS resource (retrying in 10240 seconds): Error calling PNS API 'PnsRegisterClient' (return code = 19108) 2018-12-14 23:10:23 Error: CSystemConnectorModule [Thread 6ac]: Software installation failed: GetFile: Error reading HTTP response data (0x4e33)

Continuing to have a lot of issues with this whole Apache HTTP Proxy cache. After trying to push the ESET Endpoint Antivirus to a location with a 20m connection the other day a dozen times I gave up. I tried again today, and on the first attempt it succeeded and the software is installed. I went ahead and tried another computer at another location with the same 20m connection, and now it's failing over and over again. 6 times in a row with the same error "GetFile: Error reading HTTP response data (0x4e33)". Is there a way to force ESMC 7 to push installation tasks the same way ERA 5 did? ERA 5 has pushed software installation tasks to these exact same remote sites for years without any issues like this.

Marcos - I sent you a PM. I also changed the repository per the KB to use the USA repository. I push the Endpoint client to a client on a slow 3mb connection and it succeeded on the first attempt this time. However I then tried to push the Endpoint client to a workstation on a 20mb connection and it's failed multiple times in a row.

Hello - We are trying to push out Endpoint clients to our workstations that are on slower links. We have several sites that have 20mb (Fiber) and 3mb (Bonded T1) connections. We constantly get "Failed to synchronize package repository. See trace message for more details.". Looking at the trace log we see "GetFile: Error reading HTTP response data (0x4e33)". There is nothing wrong with these connections, they are just slower. We have pushed out ESET Endpoint 5 for years to these locations and also push WSUS and other updates routinely. We can push the ESET Agent with no problem, but the moment I try to push Endpoint I get the errors. I found if I try over and over one of the attempts will finally go through, but that is just not practical. I tried clearing the Apache Proxy cache but that didn't seem to help. Anyone have an ideas?

Marcos and MichalJ - Thank you very much for the responses. Your explanations answered the question and I was able to figure out how it all works and have it deployed to a group of test computers.

Ok, that seemed to be what I was reading in the documentation and much different than what I am used to in ERA 5. As for the Proxy Server, I can see that the default configuration set it up at the Global level. I assume that only traffic between ESET Endpoint AV and the Agent is run in this proxy and none of the other computer network traffic?

Currently we are on ERA 5. I have built a new ESMC server and am working on getting the policies setup and functioning so that I can move our clients over. I am confused by how the updates are downloaded. If I want all our workstations to only download updates from the ESMC server and not have each individual client going to the internet for updates, am I required to use the Apache HTTP Proxy? In ERA 5 it was a piece of cake, turn on the Mirror and points clients to the server, but in ESMC I see all this Apache HTTP Proxy setup and it is working, but I don't know why I need a proxy server when all the clients are on the same network and can access the ESMC server directly. If I disable the Apache HTTP Proxy does that mean all clients will download updates from the web or from the ESMC server?

Same here, dozen computers so far. It looks like the addthis.com is owned by Oracle.

Marcos - We would definitely be interested in the files being restored, particularly the data1.cab. The setup files in that folder are crucial to being able to deploy future Acrobat updates. It appears that the files were only removed on some of our users computers and our guess is this is due to what the end user selected from the ESET "Threats Found" dialog box.

We just started noticing that in the last few hours every computer on our network with Adobe Acrobat DC is reporting that they have files that are infected with PDF/TrojanDropper.Agent.AH Trojan. A quick look on Virus Radar shows that this definition was added/updated today and it looks like it is a false positive. ESET is flagging the installer files for Adobe Acrobat DC as having this infection along with files in the local users profiles also placed there by Adobe. The log files are showing hits on: C:\Program Files (x86)\Adobe\Acrobat 2015\Setup Files\{AC76BA86-1033-FFFF-7760-0E0F06755100}\Data1.cab » CAB » template3.pdf28 - PDF/TrojanDropper.Agent.AH trojan C:\Users\username\AppData\LocalLow\Adobe\Acrobat\2015\Acrobat\Synchronizer\resources\resource-18 - PDF/TrojanDropper.Agent.AH trojan Anyone else seeing this and is this a false positive?

Yes, ERA v5 running 5.3.33. We do have ThreatSense.Net configured to send via ERA. I ended up moving the folder and found that ERA just created a new one. I see there are 19 files in the new folder, so it appears to be working again just starting a new collection of files.

We've noticed that the ThreatSense2_Data folder (C:\ProgramData\ESET\ESET Remote Administrator\Server\storage) has approximately 500,000 files and is 2GB in size. From the dates on some of the files, it doesn't appear to be cleaned up by any of the log cleanup tasks so I am trying to determine how to cleanup this folder. Can someone explain what this folder is for and how it can be cleaned?

It appears ESET released an alert on this issue. The fix is to install 5.0.2254 however I believe it is well documented in this thread that clients with 5.0.2254 have been experiencing this same issue. I know for sure that I had at least a dozen 5.0.2254 clients that have had this issue. hxxp://support.eset.com/alert6056/

I am experiencing the same problem here on two ERAS servers. ERAS 5.3.33 and Endpoint 5.0.2254, 5.0.2260 all on Windows 7 machines. Originally it was just one computer and a reboot solved the problem. Then a couple more computers with the same issue and another reboot fixed the problem. This morning it is now 4 more computers with different error messages: Error downloading the update - Error downloading file from the update server Error downloading the update - Could not connect to server Error downloading the update - Error allocating memory I am in the process of deleting the mirror data, clearing the update cache and then doing a clean definition update and see if that helps. *just to note - we serve our definitions through IIS and not the internal web server.

FYI - We are experiencing the same issue trying to "Upgrade Client" from 5.0.2254 to 5.0.2260 using ERAS 5.3.33.0. The package was built with both x86 and x64 and confirmed the settings are identical to previous packages that were used to upgrade the clients to 5.0.2254. I am able to deploy the client using "Windows push" to a computer without ESET, however "Windows upgrade client" fails with "No upgrade for this client". [2016-04-15 08:03:21.461] V2 [570e1c4f0000] [00000f9c] <SESSION_USERACTION_INFO> ConsoleProcessRequest: C2S_CREATE_REMOTE_INSTALL_TASK, <ERA Server> user [Administrator] created remote install task for computer: ComputerName=xxxxx, PromaryServer=ServerName, MACAddress=xxxxxxxxxxxx, AlternativeIpString=xxx.xxx.xxx.103 [2016-04-15 08:04:54.038] V2 [5711031272c2] [00000e20] <RINSTALL_ERROR> HandleClientUpgrade failed, code 3, error code: 5, gle: 0

Same problem here. Updates are crawling. I see they posted an alert yesterday ( hxxp://support.eset.com/alert5553/ ) however I'm not sure how this affects ERA downloading updates.

As a home user that might be fine, but this is the business user forums, so no it is not enough. They have a KB article spelling out distinctive sets of IP addresses used for the different parts of the software for a reason. I should be able to match the IP addresses in our firewall logs with their specific purpose on the KB article.

Our firewall logs show ESET Endpoint Antivirus accessing 38-90-226-11.ptr.eset.com (38.90.226.11). That IP address is not listed in the KB article outlining IP addresses/services: hxxp://kb.eset.com/esetkb/index?page=content&id=SOLN332 What service is this IP address used for so I can decide if I need to allow it through the firewall or not.

Patrick - Thanks for your reply. Please have your Knowledge base group keep the KB article up-to-date. Many of us have firewalls that we have to maintain, and having this list accurate would be helpful.

Bart - Thank you for the information, you were in fact correct. In the English version it is under Personal Firewall > Settings > Rule Setup. Thanks Arakasi for looking, I never would have found it either since we are running ESET Endpoint Antivirus which supposedly does not include a firewall, but the setting is under "Personal Firewall"....somehow that makes sense?

Is it possible to add an IP Address exclusion to Protocol Filtering from the ESET Remote Administrator Console? In the client it is located at Web and email > Protocol Filtering > Excluded IP addresses. It seems like I've seen it in the Policy Manager before, however today when I need to use it, I can't seem to locate the correct setting. ERAS 5.1.38

h1-c01-b.eset.com (91.228.166.45) h1-c02-b.eset.com (91.228.166.46) I have noticed these addresses in our firewall logs, but these addresses are not listed in the KB article: hxxp://kb.eset.com/esetkb/index?page=content&id=SOLN332&actp=search&viewlocale=en_US&searchid=1395679973794 I'm guessing that they are part of the ESET Live Grid but would like confirmation on this?

Have you tested to confirm that ESET is the problem? I ran into an issue with Microsoft's "Office File Validation" feature with network shares that caused a huge lag when opening specifically Excel files from a network share. We ended up disabling Office File Validation due to the issues it caused.