Jump to content

j-gray

Members
  • Posts

    620
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by j-gray

  1. Perhaps this is the case in a home environment. We have dedicated firewall appliances and dedicated web filters that handle this. We have no POP/IMAP clients.
  2. I disabled Email Client Integration entirely by policy. The client GUI accurately reflects that 'Email Client Protection' is disabled permanently. However, the critical Protection Status error persists: Email protection by protocol filtering is non-functional. In order to clear this issue I had to: Go to Web and Email policy section and turn on 'Enable application protocol content filtering' Go to Web and Email > Email Client Protection > Email Protocols and turn off 'Enable email protection and protocol filtering' Go back to Web and Email policy section and turn back off 'Enable application protocol content filtering' I had to perform step #1 because the policy item in step #2 is enabled but grayed out and cannot be toggled. It really seems that if you disable a parent policy (e.g. Email Client Protection) it should inactivate all child policies automatically.
  3. @Marcos ERA console looks like this: Client GUI looks like this: We have email protection enabled, but not protocol filtering. This is under the 'Web and Email' policy section, so not sure why it's reported as a Firewall Subproduct. Either way, this shows as a 'Critical' issue only on the latest 6.6 client. Previous versions do not show any errors, despite the same policy applied.
  4. I should also note that all of the Firewall-related statuses are disabled (both 'Show' and 'Send') via policy, as well.
  5. This warning appears on Win10 clients with ESET version 6.6.2086.1 and the latest agent. The error detail shows Protocol Filtering is a subproduct of the Firewall. We have the Firewall completely disabled via policy. Why do we receive a Critical error state for a component that is disabled? How do we fix this issue?
  6. I would definitely take a look at the clients and see what all is being scanned. Also verify your scan settings and exclusions: Are they scanning network drives? Do they have external/USB drives that are getting scanned? Are other synced items getting scanned (e.g. Google Drive, etc.).
  7. That's a good question. In the AV policy under Tools > Privileges, there are options for 'Privileged groups' and 'Privileged users' which is similar to the password protection option for Windows clients. Presumably if root has not been added there, it will not have permissions to modify ESET. You would obviously need to have an admin group (that excludes root) or another local admin account in lieu of root. I don't believe there are any protections for the agent, though. Hopefully someone from ESET support can clarify.
  8. I ran a standard upgrade task from ERA to upgrade an OS X client to the latest release. During the upgrade process, is popped the ESET splash screen to the logged on user (me). ERA policy for these clients is set to disable the splash-screen at startup. Are there any options to suppress the splash-screen during upgrade?
  9. @Peter Randziak; Any idea if this issue is caused by the agent or the AV client? I upgraded to the latest version AV (6.6.800.1) yesterday and just got the same 'update in already in progress' warning pop-up just now.
  10. I'd recommend first making sure your DNS is working flawlessly and rule out it as the cause of the mismatches. Then verify you have the 'Rename Computers' server task configured to run periodically. Also, if computers are frequently renamed in AD, or happen to get disjoined and rejoined, this can cause issues, as well
  11. I'm going to guess that this (Scanning in progress) is a bug:
  12. What step is giving you trouble? Were you able to successfully deploy the agent via GPO to newly joined workstations?
  13. The OS X client does not have the option of idle state scanning like the Windows client does...
  14. A little fishy, right? And it was still scanning today when I came in, so it's been going almost a week. We don't scan network drives/shares and my local drive is not that large. The GUI still shows 'Scanning in progress' with '0' files scanned. I rebooted several times and both scheduled scans still show 'Scanning in progress'. The icon is not animated, so as far as I can tell it is not scanning presently. There's nothing logged under 'Events', either. It's empty. Anyone have any suggestions where to look to figure out 1) is it scanning currently, 2) what has it been scanning Also wondering if it is expected behavior to start a new scan if one is already running. Also, when/how often is the 'Scanned' count updated in the GUI? Only when the scan is completed or interrupted? Appreciate any insight.
  15. Full scan is scheduled for Wednesday afternoons. Typically it is still running days later. Today is no exception as it is Friday afternoon and has been running since Wednesday. The GUI gives no useful information. Apparently the scan from last week is still 'in progress', as is this weeks scan. But two days later it apparently still has scanned zero files. Where can I look to determine what's up with the scan?
  16. The error message randomly drops down from the ESET app icon in the OS X menu bar at the top of the screen then disappears in only a few seconds --unfortunately not enough time to grab a screenshot. Again, would be handy if the app logged errors by default and didn't have to have a separate application running to log errors...
  17. If your sync is configured for computers and groups, you should see your directory structure replicated within the ERA console. The Remote Admin port is still 2222, unless you manually changed it within the ERA console (under Admin > Server Settings > Connection)
  18. I've been running the latest RC for a week or so. Just got the "update already in progress" pop-up again, so does not appear to be fixed. And of course I was not logging at the time. I did find that a short logging session generated a 250MB file when zipped up. Hopefully it doesn't get larger than that after time.
  19. Under Client Tasks, when expanding individual tasks, there appears a list of every trigger that's occurred. Some of these are ongoing tasks and still needed. However, many are expired tasks. Is there a maintenance task, or other method to clean up the expired ones without having to click on each one, select delete, and confirm deletion? Thank you.
  20. The agent seems prone to corruption. There are a more than a few threads with similar findings/experience on both Windows and OS X. Assuming the issue is not firewall, the only fix we've found is to uninstall the agent via msi. You have to use a third-party product, as once the agent is broken ERA tasks are useless. Once the agent is uninstalled, you can redeploy using ERA console. Activation and AV install both rely on Internet connection, so verify that your endpoints have connectivity and aren't blocked.
  21. Unfortunately, it is a very random pop-up. It frequently goes days without appearing and I don't think my drive is large enough to collect logs for that duration. One would think that errors in the application would be logged natively without having to jump through hoops. While I do see log files under the ESET application folder, they are all .dat files and not readable. Is there anywhere else I can look that would have any useful information?
  22. I have to say that with the OS X client I feel like an unpaid Beta Tester... Rather than bang my head against the wall some more, I uninstalled and reinstalled the client which resolved the issue. Hopefully it does not turn into a recurring issue.
  23. Still getting this pop-up several times a week. Multiple times today. Any other suggestions?
  24. Getting a pop-up on a 10.12.6 endpoint. It says, "Unsupported macOS version. This ESET product does not support your current version of MacOS 10.12.6. The endpoint is running the latest version of both agent and AV (6.5.376.0 and 6.5.600.1, respectively). The GUI cannot be opened or manipulated, as this error continues to pop up. We're running v.6.5.600.1 successfully on later Mac OS's, including High Sierra/10.13 What gives with this error?
×
×
  • Create New...