Jump to content


  • Posts

  • Joined

  • Last visited

About cpetry

  • Rank

Profile Information

  • Gender
  • Location

Recent Profile Visitors

683 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 Security preventing me from upgrading from 4.5 to 6.X. This hasn't been fixed and it's still on the ever growing list of known issues with the 6.X product line. Our contract with ESET ends on 5/2017. So we are going to have to ride it out until then. I'll continue to use ESET at home and recommend it for home use. I will never recommend it for a corporate environment as it lacks the ability to execute, as Gartner would put it.
  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 Proxy to use a proxy server. I have two update profiles, the second is set to use the ESET update servers in the event ours aren't available. Now, if we are using the Updates > HTTP Proxy setting, should the update server be set to auto-select, or should that be the address of the proxy server? Right now it's set to auto-select under Updates>Basic.
  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 since we have thousands of clients and it was really adding up. We could see it as a top 5 bandwidth hog in our netflow.
  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 Security Product for Windows > Tools > Proxy server (not configured.. asked support during setup and they told me it wasn't needed) Agent Policy: ESET Remote Administrator Agent > Advanced Settings > HTTP Proxy (this is filled out with the same information above under "Update > HTTP Proxy") Yet, if I go into the directory for the Apache HTTP proxy, I can see a ton of data being cached in it.
  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 this 1700 node installation of ESET on our corporate network. At some point it's going to be easier to replace it.
  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 problem with this duplicate SID issue is the cloned agents won't show up in the console. So there's no way I can tell if someone made a mistake and deployed a cloned agent. I could have 100 cloned agents reporting to my ERAS and only one client will show up. So, if there was a section in ERAS to even show duplicate/cloned agents, where you can easily just reset them after the fact this would be fine as well. I wouldn't mind much if I could include the agent in my images even if I had to go into ERAS, go to a special section/tab, select the cloned/duplicate/invalid systems, and reset them there. The point is there are ways around this. I just feel like ESET has put no effort into it. You did what McAfee did with their agent.
  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. Changing a single component or even two components may be fine, but changing several components may upset Windows." I already have rip and replace. It was given to me due to us having other issues getting the software on systems. I'm still left having to manually remove / install File Security for our servers. They didn't have rip and replace for File Security. That and there's a bug in ERA right now that prevents upgrades of File Security. I've tried, it fails. It really seems we are going to have to buy imaging software that can run post-deployment tasks just for ESET. No other software we have requires a post-installation task due to a unique ID of any kind. I'll just have to put SmartDeploy in the budget and account that cost towards the cost of ownership for running ESET.
  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 don't understand why ESET thought the process of the agent generating it's own static SID upon installation was such a good idea. The only purpose of this SID should be to identify a unique agent connecting to the system. I'm just glad we haven't settled on a corporate image product yet. I had to email our IT staff across the world and tell them to not use the new version in an image if they have chosen to use an image at their site until we can figure this out. Needless to say not one of them were happy about how the newer version of ESET behaves. For now I told them to remove ESET 5.X from their image if they are using one at their site, and to install ESET 6.X by hand on new systems until further notice. So now, with the procedure you've given me, I now have a total of three different procedures all given to me by different ESET employees. I'm going to follow up with that sales director at ESET and let him know this new SID process the agent uses is awful and is causing an undue hardship on us. Management over there needs to be made aware why this process is awful for bigger corporations.
  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...