Jump to content


  • Posts

  • Joined

  • Last visited

About Antoine

  • Rank

Profile Information

  • Location
  1. Upgrading at night would be a good idea if we hadn't told our users to shutdown their computer at the end of their day. It's already hard enough to get a uniform behaviour from them, so you can't change this kind of policy every other day. For now the solution will be to send them MANY NOTIFICATIONS (praying that they don't ignore them like 90% of the time), and send a reboot/shutdown/update task accordingly to the machines' need. But this is a highly inefficient and ineffective method, this is unsatisfactory. Users don't give a **** about security, to them it's wasted time, not here to judge this state of mind. But at this point, our duty as IT staff is to maintain their security solutions in to shape without involving them.
  2. Hello, Yesterday I saw the 7.3.2041 update of Endpoint and sent an update task to all the computers in the park (from ESMC). This morning I get errors on some machines stating that they need to restart to complete the update. The problem is that most of my users did shutdown their computer last night. This was already a problem with the previous update where I had to go to every problematic computer, open Eset GUI and use Endpoint's reboot button. This is tedious, and a waste of time for both me and my users. I cannot ask my users to do that everytime there's an update (and most of them will get lost in the process anyway). Also I cannot send update tasks with reboot included, the users will lose their work (even if you tell them to close everything, they'll leave some important stuff open). Why is Endpoint not able to update correctly when Windows shuts down or reboots ?
  3. Hello, I've been looking into the location you pointed, nothing seems to refer to the Agent (only Endpoint logs it seems). I'll have a look at admx update, the server is a 2012 and didn't get admx updates for Windows 10 I think. ADMX update did not seem to make it work better. I think I found the source of the problem : the computer itself wasn't in the same OU in terms of AD. It was in the GPO's security filter, but not placed in the AD 'folder' of the OU (it was still in the basic 'Computers' folder). It seems to be working now that I did that. Thanks for your help. Regards,
  4. Hi, As stated in the title, I have issues deploying remote administration agents through GPO (windows server 2012) to Windows 10 machines. My Eset server (dedicated windows 10 machine) is ESET Security Management Center (Server), Version 7.2, ESET Security Management Center (Console Web), Version 7.2 . I was able to download an .ini file with the desired configuration for the agent (from the Eset server console), and the .msi file from this URL : https://download.eset.com/com/eset/apps/business/era/agent/latest/agent_x64.msi I ran several tests with a dedicated OU, with dedicated GPO and assigned user/computer (and tried both user and computer configuration strategies). Using the same method and parameters I was able to remove a previous version of Firefox and install an updated one (.msi installer also, but no .ini), but the same process did not work for the remote agent. Remark 1 : no issue manually installing the very same agent_x64.msi file (from the aforementioned URL) from the same shared folder. Anyone has an idea ? I'm probably missing something but Eset’s ressources didn’t help ? Remark 2 : Why GPO ? The console doesn't allow to update agent remotely (the update end up with a failure message) and our IT infrastructure is starting to grow (I can't update this much machines every other month), so I need something to manage and update these remotely ; GPO seemed to be a fitting option. Thanks for your help. Ps : Eset ressource I used https://help.eset.com/esmc_admin/70/fr-FR/fs_agent_deploy_gpo.html https://help.eset.com/esmc_admin/70/en-US/fs_agent_deploy_gpo.html https://support.eset.com/en/kb6864-deploy-the-eset-management-agent-using-a-group-policy-object-gpo https://help.eset.com/esmc_admin/72/en-US/fs_agent_deploy_gpo_sccm.html?zoom_highlightsub=gpo
  5. I couldn't reproduce and the problem stopped for now
  6. I'm sorry, do you mean proxy through our ERA server or with some external Eset server ? The option is currently set at "use the global parameters" and there's no server address or credential, so I don't think we use any proxy. The option "use a direct connection if the proxy is unreachable" is on though.
  7. Hi everyone, So I have this reoccurring issue where my Eset endpoint clients cannot update as scheduled, it goes "download interrupted" in the event of the application. But then, after a few hours, it can update again without me changing anything (except waiting). I haven't found any time pattern, nor have I found any issue with my firewall (anyway updates work from time to time, so I don't think it is firewall related). This seems to also affect LiveGrid connection, which shows as "not accessible" when it happen. Internet access and DNS requesting is fine during these periods, no problem there. I already tried to empty the update cache, to no avail. So where should I look to try and solve this problem ? Anything to get more detailed logs about the error ? A bit of context : - several clients have displayed this issue, - Endpoint version doesn't seem to affect the issue (both version 6.x and 7.x displayed it), - There's an Eset management center configured, with agent on all clients, - it has happened for at least 2 months (I've arrived recently). Thanks in advance for your help everyone.
  • Create New...