Jump to content

ztimity

Members
  • Posts

    3
  • Joined

  • Last visited

About ztimity

  • Rank
    Newbie
    Newbie

Profile Information

  • Location
    Germany
  1. Phone support finally pulled through and fixed the problem for us on three seperate servers: We had to change the update type from Regular to Pre-Release, let it update the HIPS module and then the messages went away. After that we set the update type back to Regular and have been problem free for a week now.
  2. Registry key values for our three servers: BNR (my test system) - ESET Version 6.3.12010.0 - "7601.23455.amd64fre.win7sp1_ldr.160516-0600" FS1 - ESET Version 6.3.12004.0 - "6002.19573.amd64fre.vistasp2_gdr.151230-0604" DAVID - ESET Version 6.3.12004.0 - "9600.18194.amd64fre.winblue_ltsb.160112-0600" All of the bellow info is from the BNR Server: With HIPS Off, our default policy, I was able to kill egui.exe through the taskmanager. I then enabled HIPS and set it to Automatic through ERA and did a server restart, I am then unable to kill egui.exe through the taskmanager with the Access Denied error popup. I went through the HIPS Settings and looked at the rules section, both in ERA and on the server itself and they are both empty with no custom rules. I was able to add a test HIPS rule within ESET directly on the server and delete the rule afterwards with no popups or any errors anywhere that I can see. As far as I know, all Admins with access to these servers always log in with a user account that has full Administrator rights. I will send you a PM right now with access to the logs and the ticket number. Thank you for your help so far.
  3. Sorry to resurrect an old post, but I am having the same exact issue described by OP and have been trying to resolve the issue unsuccessfully for over a month with ESET Business Phone Support Germany and have yet to get any response that would allow me to rectify this error with our client. We have sent the Log Collector over to support and each time I call I get the run around and am told that I will receive a call back, but have yet to in over a month and am unable to explain to our client why this error keeps popping up daily. We have a client with around 15 Windows Server 2008R2 virtual machines, all with ESET File Security installed and configured through ERA and the shared local cache. Initially we did a fresh install on all the servers using version 6.3.12004.0. We received the HIPS error daily on three of the servers, the error pops up several seconds after the Volume Shadow Copy Service creates a snapshot on those local machines. All the servers are production machines, but I can play around with one of the three and what I have done so far on that machine without any results: 1. Clean install of version 6.3.12006.0, and then again of version 6.3.12010.0. By clean install I mean rebooting the server into safe mode and then uninstalling ESET File Security, manually removing any left over folders created by ESET and doing a reboot in between the uninstall and install of a new version. As soon as ESET is installed and up and running the error will pop up around 20-50 times right as ESET first starts. 2. HIPS is normally deactivated through the ERA policy, but we enabled HIPS as a test and set it to Training Mode, with a stop date in the future and left it like that for a week. Same error messages multiple times a day. 3. Deactivated HIPS once again. Same error message. 4. Various other HIPS settings, on/off, each with a reboot after the policy is applied.
×
×
  • Create New...