Jump to content

cpetry

Members
  • Posts

    91
  • Joined

  • Last visited

Posts posted by cpetry

  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:


     

    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. 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.

  8. 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.

  9. 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.

  10. 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. 

  11. 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.

  12. Also, I'm re-reading your instructions a few times and am not clear on something.  After you image the system, you disconnect it from the network, and THEN you run a task on the ERAS for resetting a cloned agent?  So id the SID reset on the server itself since the computer is no longer connecting to the ERAS?

     

    If that's the case, can't you just delete the system to be cloned from the ERAS and let the newly imaged systems connect as they are deployed?  If the computer with the agent isn't allowed to connect again (your step 3), how is that task supposed to run against the agent?  Unless that task isn't actually run against the agent and it's run against ERAS?

  13. This happens a lot while I'm using ERA 5.3.33 to push custom software packages (rip and replace) --

     

    Problem signature:
      Problem Event Name:    APPCRASH
      Application Name:    console.exe
      Application Version:    5.3.33.0
      Application Timestamp:    5637740e
      Fault Module Name:    console.exe
      Fault Module Version:    5.3.33.0
      Fault Module Timestamp:    5637740e
      Exception Code:    c0000005
      Exception Offset:    00202eaa
      OS Version:    6.3.9600.2.0.0.16.7
      Locale ID:    1033
      Additional Information 1:    5861
      Additional Information 2:    5861822e1919d7c014bbb064c64908b2
      Additional Information 3:    1318
      Additional Information 4:    13181ae637ac2592fac0ca2dd662cdcc

     

    I've already adjusted the maximum package size from the default on the server policy thinking it can't handle the bigger rip and replace package.  That didn't help any.

     

    The console.exe crashes but the server software continues to run and push software.  I just open the console back up and everything is still pushing/installing without error.

     

    I wish I could push custom packages with ERA 6.X.

  14. I'm trying to convince management to test Windows updates, let alone ESET updates.  It's amazing how much of a push back I'm getting on that.  They actually like having updates wide open so anyone can download whatever and install it, regardless of the consequences.  They think firmware updates are regular updates.  I've never heard of any IT department pushing out firmware updates as a regular thing, or allowing users to do it.  I blame Microsoft and their garbage Surfaces for that one.

     

    If I can convince them to do testing, I'd like to create sub-OUs for each site and put maybe 5 people into each sub-OU for testing.  I can then assign Windows updates one week earlier than our automated patching.  I can use those same sub-OUs for an ESET policy for testing pre-release modules.  I would even create a DL and put both the sys admins and testers in it so we can use that to speed up communication in the event something breaks.  You normally find out something is broken the day it happens, 3 days at most if it's during/after a weekend.

×
×
  • Create New...