Mitchell

This is possible, you just have to add the address and port to the allowed list in config. Pick the address based on the location of your ESET Inspect Cloud Instance eu01.agent.edr.eset.systems or IP 52.166.186.239 TCP/8093 ESET Inspect Cloud Connector Location: Europe us01.agent.edr.eset.systems or IP 40.83.252.19 TCP/8093 ESET Inspect Cloud Connector Location: USA jp01.agent.edr.eset.systems or IP 20.188.24.252 TCP/8093 ESET Inspect Cloud Connector Location: Japan

You can just download the latest version from the download page, run the installer and it will perform the upgrade for you. (fields such as database credentials and connection settings for ESET PROTECT should already be pre-filled)

You can download the latest version from the download section: https://www.eset.com/int/business/download/inspect/ Keep in mind that depending on your environment and the version you are upgrading from the upgrade might take several hours. Some more information regarding this can be found in the help page: https://help.eset.com/ei_deploy/1.11/en-US/server_upgrade_through_esmc.html

The following buit-in rules have an action that can result in a blocked hash. (i'm not sure which of these are enabled by-default however): <name>Process has started from Recycle Bin folder [A0412]</name> <name>Suspicious executable created in %startup% folder [A0127b]</name> <name>Regsvr32 has dropped a suspicious executable [A0311]</name> <name>Certutil has dropped a suspicious executable [A0313]</name> <name>Process executed from ADS [A0417]</name> <name>Process with mimikatz-like executable metadata executed [A0423]</name> <name>Ransomware-like data written to file [A0603]</name> <name>Multiple file writes from a compromised process [A0606]</name> <name>Multiple file renames from a compromised process [A0607]</name> <name>Remote execution using renamed PsExec service [A0905]</name> <name>Canary File was Triggered [D0334]</name> <name>Suspicious Nvidia Signed module was dropped [E0464]</name> <name>Suspicious Nvidia Signed module was loaded [E0465]</name> <name>Explorer.exe Loading Suspicious .Net Assembly [E0472]</name> <name>Suspicious Compromised Process Loading .Net CLR DLL [E0473]</name> <name>Rundll32 loaded DLL with unusual extension [F0461]</name> <name>Windows Print Spooler loaded suspicious DLL from remote folder [A0441] </name> <name>Suspicious LoLBaS Execution: Control.exe loading DLL from ADS (Alternate Data Streams) [E0437]</name> <name>Suspicious DLL loaded from Alternate Data Stream [E0438]</name> Most likely on of these rules triggered and the hash of the file is now added to the "blocked hashes" list in the Inspect Web Console under "More > Blocked Hashes"

You can download the MSI file from repository: [removed the link due to found issues, see post below] As to why it is not available on download page & more info about the changelog, I'll leave that to one of the official ESET forum members

The suggested exclusions will appear after the learning mode duration has ended.

Could you share the full install log? Note: It's probably better to contact your local ESET support.

You can create a dynamic group with the following condition: and then create a "dynamic group changes" notification for that: You could also trigger the previously mentioned "run command" task using a joined dynamic group trigger or scheduled trigger on that group to "auto heal" affected systems. (but as previously mentioned, A reboot is probably preferred)

I can't reproduce this behavior on my test system, but had a look with Promon, at some point the installer creates the file: C:\Users\username\AppData\Local\Temp\2\ESE9EA6.tmp\ServerApi.dll Could it be that some other process is preventing the installer from either writing this file or loading the dll? Maybe creating a procmon capture during the installation attempt can shed some more light on what's going on. Also msi install log might have some additional clues about why it is failing. (if log file is not created, try running the installer with: msiexec /i ei_server_nt64.msi /lvx*! ei.install.log)

Managed to get the service started by run-command task from ESET PROTECT with command: net start "ESET Service" this was only on a test VM though, uncertain if there are any unwanted side effects.

You can create a new policy in ESET PROTECT: Select the product ESET Inspect Connector (1) & define the correct hostname/IP of the server where you installed ESET Inspect Server component (2) & select the correct Certificate Authority. Assign the policy to the all group (or a different group if you prefer):

Alternatively, assign a EI Connector policy with the correct hostname / ip adres configured to the device(s) via ESET PROTECT. (assuming you don't already have a policy based on your description)

By now your upgrade is probably finished, but you could look at show full processlist query for example: https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html

I believe this step can take a couple of hours in large environments. I would recommend letting the process continue, you could perhaps monitor activity on database side to make sure it is still doing something

I'm not sure, maybe you can find it if you enable trace level logging and check the ESET PROTECT trace logs after a failed run. I do know that this behavior is identified as bug that will be fixed in a future version.

The task is used to synchronize users from AD, mainly to show some additional info about the user triggering a detection, specifically the following fields when viewing a detection in INSPECT: (the fields in AD are empty in my case, so that's why the values are 'unkown') A possible work-around is to delete all 'computer users' from ESET PROTECT (if you are not using this functionality) after that sync task should work again, but I have seen the issue come back. If you don't care about the above information in the detection events, I would ignore the failing of the task, as it is not critical functionality.

When these errors occur, do you see a spike in "event packet queue" in the EEI Server status dashboard? If it is constantly maxing out at 500+ EEI Server is most likely not able to handle the incomming events fast enough. (Database related or disk performance not sufficient)

I noticed the help page now lists "Microsoft Windows server 2022" as Supported OS: https://help.eset.com/efsw/8.0/en-US/system_requirements.html

seems to be the same for the english version:

When editing the brute-force attack protection rules the thresholds are grayed out, disabling/enabling the rule makes these fields editable. see screen capture below:

@Ievgen ParkhomenkoYou can find some example code at: https://help.eset.com/protect_install/81/api_examples/index.html?index.html

This should give you: staticgroup_name,computer_name,computer_uuid: { "Era.Common.NetworkMessage.ConsoleApi.Reports.RpcGenerateReportRequest": { "reportTemplate": { "data": { "query_usage_definition_id": 21, "used_symbol": [ { "column_id": 673, "symbol_id": 673, "aggregation_parameter": {} }, { "column_id": 657, "symbol_id": 657, "aggregation_parameter": {} }, { "column_id": 644, "symbol_id": 644, "aggregation_parameter": {} } ] }, "rendering": { "draw_chart": False, "draw_table": True, "table": { "type_id": 100, "columns": [ { "column_id": 673, "order": 0, "width": 1, "label": {"type": 1, "literal": "staticgroup_name"} }, { "column_id": 644, "order": 0, "width": 1, "label": { "type": 1, "literal": "computer_name" } }, { "column_id": 657, "order": 0, "width": 1, "label": {"type": 1, "literal": "computer_uuid"} } ] } } } } } Example output: { 'Era.ServerApi.ReportCSVResponse': { 'reportCSV': 'staticgroup_name,computer_name,computer_uuid Lost & found,desktop-vhqqkoh,3752aa8e-2675-471c-9e61-474f2fbd7eea Lost & found,exchange.lab.local,178a0124-b66d-426b-8097-fb3261146eed Lost & found,azca.lab.local,c6ef236f-6db7-4873-9e0a-14487ac9c10b Domain Controllers,azdc01.lab.local,e6f28980-eae2-49d9-85f7-db30b7042931 Desktops,azwin10-02.lab.local,8737171e-408a-4b82-a006-a31a3c51c368 Servers,eei663777.lab.local,cd3814d2-ec00-4a43-8da2-652df3491c6f Servers,localhost,4b61b044-1f82-454d-9806-b54dfa838a14 Klant A,henks-mac.local,1397d5b6-ed44-4a40-ba8d-3b78a4a692b2 Klant A,iPhone,00029835-70ca-4b37-a7bc-86849556c23e Klant A,Android,0002c0b5-0a49-41ab-a4c0-5c2d01be2d1a Klant A,henks-mac.local,2b16e91c-1497-4e6f-8c01-21f6a2c52f5a' } }

I haven't been able to reproduce the issue on the latest version of ESET Endpoint for mac OS (6.9.60), So upgrading seems to be the easiest fix. Edit: I'm not sure if there is a newer version of ESET Cyber Security though.

Seems that creating the following rule is sufficient: Name: Allow Teams Helper App: /Applications/Microsoft Teams.app/Contents/Frameworks/Microsoft Teams Helper.app Action: Allow Direction: In Protocol: TCP & UDP Ports: Remote Remote Port: All Destination: Entire internet