Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


j-gray last won the day on April 12

j-gray had the most liked content!

Profile Information

  • Location

Recent Profile Visitors

1,301 profile views
  1. j-gray

    Protocol filtering is disabled

    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. j-gray

    Protocol filtering is disabled

    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. j-gray

    Protocol filtering is disabled

    @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. j-gray

    Protocol filtering is disabled

    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. j-gray

    Future changes to ESET Endpoint programs

    Exactly. Though I view wake-up call more like wake-on-lan, requiring network broadcast, which is not a good practice across multiple subnets. I'm looking for a simple 'send policy' that doesn't require network broadcast. Even if it's a basic command I can run from the client (remotely).
  7. j-gray

    Future changes to ESET Endpoint programs

    Description: Mechanism to force policy refresh on client(s) from ERA console. Detail: There doesn't appear to be a way (that I've found) to force a client to pull a new policy. We either have to wait for the policy refresh interval or create a new policy with a shorter refresh interval and apply it. It would be great to have a right-click option from the ERA console to force an immediate policy refresh.
  8. j-gray

    Future changes to ESET Endpoint programs

    Description: Better method for detecting unmanaged clients Detail: RDS is not a practical solution in environments with multiple LANs, it can't be installed on OS X, and relies on outdated/unsupported software (WinPcap). A simple ping-sweep tool that works across multiple subnets and shows unmanaged clients, or better yet, a dynamic group that does the same so that an agent install task can be run when client joins the group. This would be awesome, especially for OS X where Group Policy automated install is not an option.