Jump to content

jcook

Members
  • Posts

    6
  • Joined

  • Last visited

Everything posted by jcook

  1. No we did not have ESMC 7.x installed. We are always pretty much up to date and were using v10.x.
  2. I have exactly the same issue after upgrading our ESMC to the latest version (yesterday) and pushing agent upgrades to the clients. At least one of the clients never came back online. On that client I noticed the "Eset Management Agent" was not running. Starting it resulted in error in Event Log: Then I investigated the "C:\ProgramData\ESET\RemoteAdministrator\Agent\EraAgentApplicationData\Logs\ra-upgrade-agent_2024-01-03T19-13-24.log" file to see if I could find any clues. I found pleanty of errors like this: Info 1603. The file C:\Program Files\ESET\RemoteAdministrator\Agent\xxxxxx.dll is being held in use. Close that application and retry. Error 1321. The Installer has insufficient privileges to modify this file: C:\Program Files\ESET\RemoteAdministrator\Agent\xxxxxx.dll. I don't understand why the upgrade suddenly had not enough privileges, but clearly the agent was not upgraded and because it could connect to the server anymore, a manual reinstall of the agent was the only solution. Hence I downloaded the latest version of the installed from our ESMC and ran that on the client. That did not solve the problem because those downloaded installers are unable to upgrade Agents that are password protected. So, I modified the PROTECTAgentinstaller.bat as explained here. Running this modified installer redeployed the agent successfully and after a reboot the agent connected again. So, I'm good for now. But clearly the initial agent push upgrade failed and I will have to wait and see if other clients will have this same issue. And yes, this client also was a Windows 10 machine. I hope this report helps anyone.
  3. There is another problem that makes the downloads so big: Every day large 'updates' are being downloaded. You can easily test that. Make sure your client is up to date. Then disconnect them from the proxy (eg pull out network cable). Wait 1 day. Open the Eset client and get ready to force refreshing the updates. Start making a screen video, put the network cable back in and hit the refresh update button. You will notice the first a small download is fetched, which is normal after 12 hours (a level 3 update). But immediately after that a very large download comes in (a Level 1 download). You might say this can happen, bit this happens every single day. ESET needs to fix this urgently, because their small updates was one of the last USP. I would hate to loose that.
  4. We have noticed exactly the same problem with one of our customers. And he could easily reproduce it in a lab with recommended ESET setup. One observation is that all update calls to hxxp://update.eset.com/ are redirected by that server to umXX.eset.com servers. So the files are downloaded from those umXX servers. But identical .nup files on those servers are not seen as identical by the proxy. Meaning the cache for a .nup file is only hit if-and-only-if it comes from the same umXX server. So, if you have for example 10 clients asking updates, via the proxy, to hxxp://update.eset.com/, then in practice only a fraction is hitting the cache due to the round-robin redirect policy from hxxp://update.eset.com/. I hope you are able to reproduce and fix this asap because, well, ... our customer uses satellite connections, so it hurts ... a lot.
  5. Hi @Peter Randziak, any update on this? I too am interested in getting Powershell to work the ESMC API. Some simple working examples is what I'm lacking at the moment.
  6. I see ESET Endpoint Antivirus for OS X version 6.8.2.0 available in the repository, but find no release notes, nor any mention here. Any info available? Thank you
×
×
  • Create New...