Jump to content

carmik

Members
  • Content Count

    112
  • Joined

  • Last visited

Profile Information

  • Location
    Greece

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. We have purchased Remote Utilities and installed it for IT support purposes. Some days ago due to our ESET license expiring and till the renewal taking place we decided to enforce the antivirus-maximum protection policy. Today around 100 Remote Utilities installations were eradicated. Upon investigation it seems that the specific ESET policy switches potentially unsafe application handling (reporting and protection) from off to balanced. This action had us running around, trying to restore connectivity for teleworkers. Until I found out that the policy to change was the one written a
  2. It was a network/proxy issue after all. It was resolved today and I my tasks are operating just fine now (ie I can assign all products). Consider the case solved. And thank you for your help.
  3. @MartinKsome more comments. First, I believe that the KB relevant for our case is kb7811, since we are using ESET Protect 8 and not 7. Now, after reading that KB article it would seem that if we are able to access hxxp://repository.eset.com/v1/info.meta we should be ok (considering our server was set to AUTOSELECT), but although we download the info.meta from this link successfully, we still do not see all the products available for inclusion for a ESMC task. My understanding of what is meant by KB7811 is that we should be ok and we should look no further? Perhaps the article should
  4. Access to repository.eset.com is ok, whereas repositorycdn.eset.com fails. We are still waiting for resolution.
  5. @MartinKthe issue is that trying to wget something from hxxp://repositorycdn.eset.com gets a zero sized reply (502 or 503 http error IIRC) from our WAN proxy array... Access to repository.eset.com is ok, and that is why we can "see" some products in the task, whereas others do not appear.
  6. An update on the case. We had a thorough, multi-hour troubleshooting session with ESET local support and isolated the issue to be possibly located to the array of the network-transparent proxies. I've opened a ticket with them and anticipating a resolution hopefully by tomorrow. It really helped that a colleague of the ESET bloke I was discussing with had a similar problem from another organization within the same WAN, indicating some sort of network issue. Oil's well, will update when the thing is fully resolved.
  7. I've sent the details at noon, containing a link to this thread, hope I'll be hearing soon. As for the network itself, your concern is well-founded, however there are another 6 LANs like my own, all in the same corporate WAN, that (AFAIK) are fetching updates without any issues. An array of network-transparent proxies performing layer 7 filtering intercepts all outgoing traffic, affecting all LANs. This is not under my control though. Of course something might have gone bad there and my colleagues at the other installations have not noticed it yet... Is there some tool I could use fr
  8. Regretfully, the issue re-appeared. In the first place, the cause was my fault: after the network changes I neglected to change server settings on the eset protect web console to direct the server to fetch updates from the new network proxy (essentially the apache proxy running on the same VA). I updated the settings, setting protect to point to new ip and I started seeing again the ESET Endpoint Security repositories. It all went fine for a day or two. Today I tried to run the same task, but my eset endpoint install tasks failed with a unable to find repository message. Editing the
  9. Never mind, issue solved. It was a misconfiguration after the re-numbering of our ip range, which although it happened 3 weeks ago, eset protect just now complained... Case solved, thanks again for your help.
  10. @Marcos please disregard my question about pcap, did not notice that you've mentioned tcpdump in the process. I do have a number of questions regarding the log files I should submit. Specifically at https://help.eset.com/esmc_install/70/en-US/log_file.html three files are listed for v7 of ESMC: /root/appliance-configuration-log.txt, /var/log/eset/RemoteAdministrator/EraServerInstaller.log and /var/log/httpd (which is a directory). I have ESET Protect (v8) as a virtual appliance (updated from ERA -> ESMC -> ESET Protect) installed, therefore I do not know if the files/directorie
  11. 1) Which pcap log are you referring to? Should I get a tcpdump on the network interface of the VA? 2) Should the ticket be opened with ESET local (national) support?
  12. I believe I'm not using the ESET proxy (IIRC that was a product to mirror ESMC server installations). I'm using the bundled Apache HTTP proxy: # rpm -qa |grep htt httpd-2.4.6-97.el7.centos.x86_64 httpd-tools-2.4.6-97.el7.centos.x86_64 httpd-tools-2.4.6-93.el7.centos.x86_64 From the logs (/var/log/httpd/access_log) it seems it is running normally. Apache connects directly to the internet (no upstream proxy).
×
×
  • Create New...