Jump to content

Peter Randziak

ESET Moderators
  • Posts

    3,511
  • Joined

  • Last visited

  • Days Won

    207

Posts posted by Peter Randziak

  1. 3 minutes ago, Estrelo said:

    What you have pinned in the forums is the wrong advice! Servers that haven't rebooted still have the real time protection working. If you reboot you lose malware protection. Rolling back updates does not work.

    Tested with Eicar file. Please advise people NOT TO RESTART THE SERVERS until the issue is solved!

    Yes I admit that the information provided in the alert was not up to date and accurate. The situation was quite dynamic and new findings were emerging...

    As of now, it is up to date https://support.eset.com/en/alert8521-error-during-auto-updates-in-eset-server-security-for-microsoft-windows-server 

    We apologize for the inconvenience caused.

  2. Hello @OlafB,

    I assume that it is just a misunderstanding.

    This seems to be related to End o sales of some of the offerings i.e. not the product themselves.

    I may assure you, that the currently deployed products will stay functional according to our EoL policy, available at https://support-eol.eset.com/en/index.html

    When it comes to the ESET PROTECT Virtual Appliance, which is currently based on CentOS there will be a communication covering it, but one of the options for our customers will be to migrate to a new ESET PROTECT Virtual Appliance, based on a supported distribution.

    Peter, ESET HQ

  3. Hello @Andi316,

    you are welcome.

    As of now it is not possible to schedule the VA scan twice a day. Each scan costs some amount of resources and the VA DB is not being updated that often.

    An undocumented work-around to run the scan again is to unassign the policy enabling the VA, this will remove the VA related data from the endpoint and assign it back.

    The feature is under development so I assume that more options and things will get covered over time...

  4. Hello guys,

    O.K. I understand what we talk about now.
    The file has been signed by a recognized certificate so it had higher reputation.
    The signing certificate had been revoked, so it had been removed from the list of recognized signing certificates.
    Our teams are looking into it and checking the underlaying processes speed up recognition of such in the future.

    @IvanL_5306 thank you for pointing on this, really helpful for us.

    Peter

  5. Hello guys,

    thank you for the feedback provided.

    When it comes to release of the 7.4 to the ESET Repository again, the plan is to do it during this week, I stress the plan 🙂 
    A hotfix build will be released, i.e. not just the version, which was there before.

    We admit, that the issues mentioned are not directly related to Sonoma, but rather to the 7.4 build, yes we might have named the alert article differently.

    I passed your feedback internally to people responsible for the macOS product.

    We apologize for the inconvenience caused.

    Peter

  6. Hello guys, @obee / @Mitchell,

    ESET services should be allowed by default.
    Make sure that you have the latest version of ESET Bridge deployed / you use the config from the latest version and try it with it.

    In case the communication to an ESET service is blocked, please provide us with the Bridge logs capturing the attempt tp connect to it with the info verbosity set and of course the address of the service, you are trying to connect to.

    Peter
    note for us: P_EB-704

  7. Hello @j-gray,

    19 hours ago, j-gray said:

    @Peter Randziak Ok, if I understand correctly, you're saying that the Bridge can cache updates (modules, product updates), etc.) for OS X as long as the requests are via HTTP and not HTTPS? If that's the case, then great.

    Yes the ESET Bridge or any standard proxy with the caching enabled.

    19 hours ago, j-gray said:

    The documentation is a bit confusing, then, as there's no mention of HTTP traffic and the only list of supported products I could find were Windows and specifically not OS X.

    Well the documentation stats what is supported for the HTTPS traffic caching, I admit that the behavior for http / macOS might be not that obvious from it 🙂 

    It is stated as 
    "Cache and distribute updates to client computers and installation packages to ESET Management Agent."

    I submitted an improvement request for the Docu team to make the info more easy to understand.

    19 hours ago, j-gray said:

    Thanks again for you help. I appreciate your presence here, as well as the other ESET folks.

    Thank you for your very positive feedback provided, really appreciated.
    We are also glad to have you, as a very active and cooperative user on the forum.

    Peter

  8. Hello guys,

    as my colleague Marcos stated, in the products for the home users, the notification cannot be disabled as it will prevent future upgrades of your ESET protection.

    The migration / Windows upgrade is not necessary, just installation of an update bringing the ACS support is needed https://support.microsoft.com/en-gb/topic/kb5022661-windows-support-for-the-azure-code-signing-program-4b505a31-fa1e-4ea6-85dd-6630229e8ef4

    The notification can be disabled in the ESET security products for business users, where the administrator is responsible for the system and it's security.

    Peter

  9. Hello @j-gray,

    18 hours ago, j-gray said:

    Thanks for the reply. The document you linked looks like firewall info, so does not appear to be relevant.

    You are welcome, well yes it covers services which needs to be allowed on 3.rd party firewall.
    It lists the services to which the ESET products connect to (vast majority of them) and those need to be allowed in the ESET Bridge ACLs as well...

    18 hours ago, j-gray said:

    ESET's bridge documentation, lists support only for Windows platforms and states specifically, "ESET Bridge does not support HTTPS traffic caching for ESET security products (and their versions) not listed above—Linux/macOS security products and earlier Windows security products."

    yes that is for the HTTPtraffic as that needs to be intercepted by the ESET Bridge in order to be cache-able.

    18 hours ago, j-gray said:

    I'm primarily interested in caching downloads and updates, but from everything I read, only Windows and Linux clients are supported. Meaning that we can't cache anything for OS X clients.

    The module updates are by default served over HTTP so they can be cached by ESET Bridge.
    By Downloads I assume you mean those served from Repository, right?
    I assume that yes, those are being served by HTTP as well, for example the latest agent for macOS is being downloaded from http://repository.eset.com/v1/com/eset/apps/business/era/agent/v10/10.1.3267.0/agent_macosx_x86_64.dmg so it can be cached by ESET Bridge / standard caching proxy as well.

    Peter

×
×
  • Create New...