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.