Jump to content


  • Content Count

  • Joined

  • Last visited

Profile Information

  • Gender
  • Location

Recent Profile Visitors

646 profile views
  1. This started happening to us on a network of over 1,500 nodes. We had to start disabling the firewall via policy on all affected systems. If you call ESET support they claim no one is complaining about the issue. This isn't the first time ESET has randomly taken our business down in the middle of the day. Both version 6.3 and 6.4 are experiencing the issue(s).
  2. Okay, I've upgraded from 6.3 to 6.4 and the known issues list just gets bigger. It's obvious ESET isn't the same company it was years ago. It feels like they lost their best programmer or something. I can't stand the issues I'm having anymore and it's time to say goodbye to ESET as a corporate solution. I'm having quotes pulled right now for both Kaspersky and Trend Micro. ESET isn't even in the top quadrant with Gartner and I know why now. After using ESET for over 3 years in a business environment I can see this is a home product. There's still a bug with ESET File Securi
  3. It should have still worked IMO: https://help.eset.com/ees/6/en-US/index.html?idh_config_connection.htm I set it under tools>proxy and just made sure to enable "Use direct connection if proxy is not available". I remember updates failing with Updates > HTTP Proxy, being set until we fixed the credentials. So it was authenticating. I know it was since the clients were having authentication errors while trying to update until we fixed the username/password in the Apache config. Technically, setting the global setting shouldn't matter since I have it set in Updates>HTTP Pr
  4. Yeah, the Tools>proxy server was blank, but under Updates > HTTP Proxy, that was filled out. This is how all three of the ESET engineers had me configure it.. I added the information into all of my policies for Tools>proxy. I kept the HTTP proxy information filled out for now. I have both an ESET and Apache HTTP proxy setup to use the same FQDN internally and externally. I'm going to monitor the behavior of the clients and see if anything still attempts to connect to the ESET update servers directly. I'll post back after a week of usage. It was obviously not working si
  5. I'm not sure what's wrong with our config but we've been helped by a total of three ESET engineers. We are looking at our firewall logs and netflow information in Solarwinds and we can clearly see over 30 GB of updates being pulled over port 80 from the ESET update servers. In our policies we have them setup to use the HTTP proxy. Does it also have to be set under Tools > Proxy server? Policies: Endpoint Policy: ESET Security Product for Windows > Update > HTTP Proxy configured with username/password pointing to the installation location of the Apache HTTP Proxy ESET Se
  6. Okay, so this is still a problem. This ERA 6.X software is probably some of the buggiest software I've used. I have a strong feeling next year we will be replacing ESET another product. I keep being pushed away when I bring up issues. To top it off the Apache HTTP Proxy isn't even working correctly. It's setup and three, yes three, ESET engineers helped me setup the Apache HTTP Proxy. Well, we've seen over 30 GB of data being pulled from ESET's update servers, crushing our network, indicating this Apache HTTP Proxy doesn't work as described. I'm becoming tired of defending thi
  7. I just noticed this in my business 6.x product. I can't find any information on it. Can anyone elaborate? Does this just crank the dial up on the advanced heuristics sensitivity? Or does it add logic? What are the false positives like with it on?
  8. Well, not a fan of this manual process. :-( 1) Use agent installer batch file (make sure to run as admin in elevated cmd prompt) 2) Push client software from ERAS to system after it starts reporting in the ERAS (this fails) 3) Install client software manually (this works) 3) Activate product with activation task Edit: Well, I finally fixed the remote push. I need to run two Apache HTTP proxy agents. One locally and one in our DMZ. I'm just using the same username/password for it so I can get away with one config.
  9. Or you can do this this way: 1) When the agent connects to the ERAS with a duplicate SID the ERAS generates and assigns a new SID to that agent. 2) The agent could use a "version number" for the client, like active directory, or DNS does to identify what system is "newer" so the older client doesn't get the new SID. 2a) The version number can be assigned before the SID by ERAS, this way the ERAS never assigns the same version number, or, the version number can be generated locally by the agent in addition to the SID, and it can use something like the date/system time. My pr
  10. How am I supposed to get it on a file server for acquired companies that don't yet have network connectivity? I have a rip and replace package for Endpoint Security but there's no such thing for File Security. We like to get our security products on a newly acquired company before we bring them onto the network.
  11. Also, I don't understand why you couldn't have just used the hostname. Yes, it can change; so what? The worst that would happen is you have the client connect to ERAS with the new hostname and the old one just sits in the console waiting for cleanup or manual deletion. I can also say from managing a network that's approaching 2,000 nodes that renaming a system isn't something that's done often. Servers are never renamed for obvious reasons. I don't even see workstations get renamed. All you're doing with this static SID is causing extra work for your customers.
  12. I've never had an issue with ERA 5.X and things changing over time. There aren't many AV applications that generate a unique ID. Basically the agent just has to tell the server who it is. I find it hard to believe there's no way to do that without generating some static SID during installation. Windows generates a hash for hardware changes. It doesn't get triggered with small upgrades. So there has to be a way to base the SID on something solid that wouldn't tie the customer down to this crazy cloning process. "The motherboard and CPU, hard drive, network card, graphics card, and RAM
  13. I really hate ERA 6.X. I'm not even kidding. This release has been one of the biggest steps back I've seen any company take in years. It's like McAfee bought ESET and forced their ill will upon them. Other ways ESET could have done this (yes, I just thought all of these up randomly just now): 1) SID is the systems MAC or a hash of the MAC. 2) SID is the systems hostname or a hash of the hostname. 3) You could even have a registry flag you can set to delay the generation of the SID on the system you install the agent on for the "next reboot" (like sysprep for Windows). I
  14. If the server cleanup task is run and this client is removed from the ERAS will this task still run when "A" that no longer even exists in the ERAS connects?
  15. Oh boy.. The rest of the IT staff is going to love that. You guys took a play from McAfee. That's exactly what I thought the process was going to be like. So we are going to have to keep a very controlled image creation process with this agent in play.
  • Create New...