Jump to content

Erlend

Members
  • Posts

    28
  • Joined

  • Last visited

Everything posted by Erlend

  1. disabling HIPS 7.3.12006 seems to resolve the issue, but we use HIPS with 7.3.12005, so something must have changed. we will run some more tests, but HIPS seems to be the source of the issue.
  2. local support have always been slooooow, and eset log collector won't help, since it's non persistent.
  3. Hi, as stated it Citrix PVS, so non-persistent, only option is to update the image with one of the following changes: -downgrade FS to the previous version 7.3.12005 (re-install with this version) -uninstall FS, not an option -uninstall component, by component HIPS, Network protection we have 6 other images with older version of FS without the issue.
  4. Hi After upgrading file security from 7.3.12005 to 7.3.12006 we are experiences a high number of hang during reboot from network. (Citrix PVS) any known issues with this version that would cause this ? since this is non-persistent there are no logs as standard, and we would need to redirect the needed logs to persistent storage.
  5. Hi anyone else encountered this being reported as infected? triggered during windows update. Time;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here 26.01.2021 14.53.10;Real-time file system protection;file;C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Host.win-x64\5.0.2\runtimes\win-x64\native\apphost.exe;Win64/Patched.U trojan;deleted;NT AUTHORITY\SYSTEM;Event occurred on a new file created by the application: C:\Windows\System32\msiexec.exe (9D336636A328D5B3F315093D86E4199A0FD7A5FC).;0DBB86B65FBBB41660DF36ABA0CED8FA4048FD7F;12.12.2020 03.44.18 26.01.2021 14.53.20;Real-time file system protection;file;C:\Program Files\dotnet\sdk\5.0.102\AppHostTemplate\apphost.exe;Win64/Patched.U trojan;deleted;NT AUTHORITY\SYSTEM;Event occurred on a new file created by the application: C:\Windows\System32\msiexec.exe (9D336636A328D5B3F315093D86E4199A0FD7A5FC).;0DBB86B65FBBB41660DF36ABA0CED8FA4048FD7F;12.12.2020 03.44.18
  6. unassigned the default policy File Security for Windows Server - HTTP Proxy Usage now. i will report back how it goes after a few days.
  7. it's set in the default policy: File Security for Windows Server - HTTP Proxy Usage
  8. hm, yes i see that now it's configure to connect via the ESET management server.
  9. Hi again @Marcos, we see both activation errors and live grid communication errors at random how can we figure out what the issues is?
  10. Hi what's the hostnames for ESET LiveGrid and ESET License servers?
  11. what do i need to include in ESET Log Collector?, don't won't to upload any unnecessary information here.
  12. the servers are connected directly not via proxy the issues seems to be intermittent, sometimes it's ok if i check for updates 5 times one of them can be ok are there any logs i can check on the client, to see what source is used for updates?
  13. Hi any know issues with updates at the moment?
  14. @Marcos same issue, i have sendt the license details in a private message.
  15. one more thing, do you have a internal system to make local support in different countries aware of these kind of issues? i contacted ESET support in Norway, and they needed to check and get back to me.
  16. no, both ESET shell and GUI is non-responsive (not able to start them), but i can access the file system remotely on the affected servers. is the module a separate dll file?, that i can check the version on?
  17. is there a way to kill the update process and ESET? to avoid reboot.
  18. after a reboot it probably sort's itself out, i have only one server that needed a second reboot before the issue was resolved.
  19. it's also affecting servers without the RDS session host role installed, we are in the process of identifying all of them. is there a way to kill the stuck update/eset without doing a reboot?
  20. can i check this directly from the file system remotely? but can you answer if there is a known issue or not?
×
×
  • Create New...