Jump to content


  • Posts

  • Joined

  • Last visited

About russell_t

  • Rank

Profile Information

  • Location
  1. Confirmed, working now in California, USA as well. My guess is someone mucked up whatever updates valid license files on the update servers or a partial file was synced up or something like that. Might be hard to catch that type of thing internally but hopefully it won't happen again... Thanks everyone
  2. I have also sent license details and ESET Log Collector log in private message but need to sleep now will check back in morning.
  3. Thanks makes me feel better that it's not just me while I delete the hundreds of emails I've also filled out an online support form here ESET North America Support » Business & Enterprise (Server Product) Support » Modules update error or other error message https://www.eset.com/us/support/contact/ Just to see if that helps get it solved faster.
  4. Just getting flooded here with what seems to be every single ESET File Security server complaining about "Update authorization failed. Please check if your license is valid." Checked and license usage is less than the total as well, is there something wrong with the Update server or should we contact support about the licensing issue? Thanks
  5. Cool I'll boot it back up and update now, this was a pretty bad one since it borked out Exchange... I can kind of see how it could be missed as without triggering the recompile of the OWA dlls it could be hard to catch in automation but it would be appreciated if that's figured out before the next panic attack.
  6. Thanks for posting this here as well, came here first and didn't see a peep, can also confirm this is happening on multiple Exchange 2010 servers. Thanks for the spiceworks link!
  7. Working again for me as well. I know this has happened in the past once or twice as well but usually it came back quicker. Is there any suggested remediation when/if this occurs again? Are you changing the DNS entry of the repo server so we should flush DNS caches or is it some other internal issue where we can't do anything that would help?
  8. Yup, exactly the same scenario I'm experiencing as well, on 6.5.522 and with the Us repository settings...
  9. Hi, I am also seeing this on about 35 clients on 5.0.2237 Doesn't sound like updating will fix this? Can you also PM me instructions? Thanks, Russell
  10. We have 40 configs because we have different email reporting settings and scheduled scan settings based on each regional group (CA, NV, UT, etc) It's actually rather easy right now, we just copy the XML config, find and replace things in it and save it as the new config, then save as in manage packages, give it the new name and pick the xml config, then export the EXE and rename it. The problem is that we need to email out the exe installer to these end users and just have them double click it, and have it go into the right group. We have no idea what they have named their BYOB computers, so it's hard to just put them in the right group after the fact. It is administrative hell but it was really easy in ERA 5 and before, which is why we chose ESET in the first place. The parameters for dynamic groups aren't able to do this, so we would end up with everyone in one group with one config and have to manually move them after confirming computer names. We don't like the HTTP Proxy for security reasons, we aren't allowed to run a proxy server open to the world. So it's good to hear that the mirror is coming back. The install with custom configuration is highly necessary as well so hopefully that will be added back. I think we'll just have to wait it out. I've spun up another VM to run ERA 6 just to keep playing with it on a few computers and make sure the client is stable and still performs well.
  11. Ok, so lets see if anyone has any ideas about how I can do this better... I use ESET RA 5 right now with 400 clients. I use Mirror for updates, and I use IIS to serve those updates (virtual directory/password control etc) since the ERA HTTP server has always been slow and buggy. I have about 40 different XML config files, that I export installers for from RA 5 to the single EXE, then distribute and script/deploy for install. None of the systems are on domain or even attached to each other so push from RA has never been an option. I need to maintain everything including the separate client installs, and the single file installs. This was easy with the manage packages and export to logon script method. I need to migrate individual user by individual user, AKA I can't just rip all V5 out over a weekend and have V6 running the next day. It will take at least a week or two to move through all the users and make sure they all upgrade, so I need to keep updates working for V5 during this period. Also, I've been reading about lots of slowdowns and other complaints about V6... I just went through all the licensing mess, and if that was the only major change I'd be fine with it... So I really can't see how I can achieve this upgrade until the following are complete: 1. Way to maintain and deploy agent and endpoint together as a small! EXE installer with unique XML config per group. This should seamlessly upgrade over an EEA v5 with a password as long as the new password is the same. I need to do this in one step and not have to find the computer name and move it to a group later. 2. Way to have the ERA server download mirror updates to a folder so I can preserve IIS hosting updates and keep EEA v4/v5 clients updating at least during the install. I'm NOT using the EFSW client to do this, and it would be nice to have options for signature update release based on the group (rapid/normal etc) So far this is a huge step backwards and I'm not even getting into how poor the new UI design is. I think I'm going to have to spin up another VM just to run ERA 6 in transition, but I'm not looking forward to dealing with these issues. Any ideas on how to get around this, or should I just wait for ERA 7?
  • Create New...