MichalJ

Hello,
Manny, thanks for your suggestion. We have in the backlog the reworking dynamic groups or, better say, enriching them to be possible to consider also data on the server (console).
For now, you can try a workaround (but not ideal) to filter servers based on OS name and exclude domain controllers by the "Not equal" condition for specific machines.

In the future, we will try to extend Dynamic groups / Dynamic group Templates to better-fitting this kind of need.

Hello, EEI support for Linux should be released within next major release which will come around end of Q1/ beginning of Q2/2022. 

You can disable it via an agent policy:

Hello, EEI support for Linux should be released within next major release which will come around end of Q1/ beginning of Q2/2022. 

Got this from ESET Support. Worked for me. Might help others:
please go to ela.eset.com and enter your 20-character license key (disregarding the email address and password boxes) and click 'manage license' at this point, an alert saying that a password reset link has been sent should appear, if it prompts for a password, please click the forgotten password link from the email link, please set a new password for your license please then go to eba.eset.com and once logged in, please add your license (hxxps://help.eset.com/eba/en-US/index.html?import-licenses.html) using the license key and password you created earlier in these steps

Hello, I have briefly checked it. And the EI Agent is reported back to ESET PROTECT the way how it is installed - meaning just first three digits. I will check it with the EI team, as it seems that this might be related to the fact, how EI installer reports its version number to Windows. Thanks for reporting. 

So it is now tracked as bug, and will be hopefully fixed in upcoming releases.
Internal reference: P_EEI-10928

Inspired by some recent posts here, I figured out how to create dynamic lists of computers with McAfee or Java or anything installed. My RMM does a lousy job of this, so this is *so* helpful. 
One thing that threw me off in the past is that the report is blank right after the creation. You need to wait awhile for it to fill in.

Here you go, a rule to detect UltraViewer:
        <definition>             <process>                 <operator type="or">                     <operator type="AND"> <condition component="FileItem" property="Extension" condition="is" value="exe" />                         <condition component="Module" property="SignerName" condition="contains" value="DUC FABULOUS CO.,LTD" />                     </operator>                     <operator type="and">                         <condition component="FileItem" property="Extension" condition="is" value="exe" />                         <operator type="or">                             <condition component="Module" property="InternalName" condition="starts" value="UltraViewer" />                             <condition component="Module" property="OriginalFileName" condition="starts" value="UltraViewer" />                             <condition component="Module" property="CompanyName" condition="starts" value="DucFabulous" />                             <condition component="Module" property="ProductName" condition="starts" value="UltraViewer" />                         </operator>                     </operator>                 </operator>             </process>         </definition>  

Hello,
Unfortunately, the "auto update" setting does not work for Endpoints V8, and only for V9+. 
In order to enable "auto updates" for V8, please configure this setting accordingly: 

Also, it is important to remember, that even when the "auto update" is enabled, it does not mean that you will get the newer version immediately after its release. Versions are rolled out over time, starting approx. 1-2 month after the formal release into the repository. 
You can read more info about it here: https://help.eset.com/protect_cloud/en-US/auto_updates.html

Hello @j-gray
In case it is an upgrade - there is no impact. Any ESET application should keep its license data upon upgrade.
In case of fresh install, in case of Mac EEI Agent, there is none, as there is currently no "activation functionality" implemented in V6 Mac Endpoint for EEI agent. Meaning, it would work, even without supplying the license data. This will change once we release new version of Mac Endpoint. 

Hello @Ufoto
Tags are currently not available to be used in "dynamic group templates" as those are used for "agent side automation" and meaning the particular data, needs to exist on the "agent side". Tags are applied on server, agent is not aware of their existence. 
If you want to do it for quicker filtering, you can easily create "filter preset" that will filter out only machines with particular tags. And over the selection, you can then execute tasks, however with the issue, that those won´t happen automatically. 

Hello @Trooper Can you please share with me your license details via private message. I will get in touch with the Early Access Team, to check, whether we still have capacity to handle additional customers.  As said, the GA release is some 10 weeks away at this moment. 
Do you have any previous experience with running our EDR on-premises, or it will be your first "touch" with the product? 

Thank you @Empty for your response. 
ESET INSPECT Cloud (new name of Enterprise Inspector) should reach general availability by end of Q1. We are already running early access program with selected customers, to tweak the product in production before general release. 
With regards to the datacenter location, you are right, we currently do not offer data center in Australia. How many clients do you have, that you would like to move? I will sync with the team hear, if we can´t put together a step-by-step guide. However, one warning upfront -  your data (previous detections, policy assignments, etc) will be lost, during this transition. 

Hello,
You can find it in task execution details and click on "history" for a particular failed client: 

Hello @j-gray. Reasoning is, that the current (old) version of the EEA / EES for Mac does not have the licensing callback implemented. Meaning, the EEI agent tries to contact EEA / EES, to verify it´s license, but the product can´t respond. This will be implemented in the Endpoint for Mac V7, which is currently in early access program. 
This does not have any impact on the product functionality. 

I know it is an old topic, but since there is no resolution yet, I decided to share the workaround I found.
Although you can't create Report or Dynamic Group template based on missing EDTD license, you can do the opposite - create such for systems having it activated. 
So what I did was to create a Dynamic Group which collects all systems with applied EDTD license and then I tagged all devices inside this group with a specific tag. I did this over the course of few days in order to make sure all active systems have the tag. Then you can identify systems which don't have the tag (thus don't have EDTD activated or offline for a while) by simply ordering the systems in the 'Computers' view by Tags.
I hope this helps some other struggling souls out there

Hello,
Unfortunately, the "auto update" setting does not work for Endpoints V8, and only for V9+. 
In order to enable "auto updates" for V8, please configure this setting accordingly: 

Also, it is important to remember, that even when the "auto update" is enabled, it does not mean that you will get the newer version immediately after its release. Versions are rolled out over time, starting approx. 1-2 month after the formal release into the repository. 
You can read more info about it here: https://help.eset.com/protect_cloud/en-US/auto_updates.html

Hello @Trooper
In case you have "upgraded" your previous license to be a "cloud eligible", you do not have to reactivate your endpoints. They should keep working, with the license just changing on them transparently.  For other questions, I believe that @MartinK and @Marcos will be able to help you. 
 

Hello everyone,
The recently discovered Log4j remote code execution vulnerability has affected organizations, ESET customers and their IT teams around the globe and as cybersecurity professionals we need to ensure their safety.
Our Research & Threat Analysis team has responded rapidly and done a great job of creating a package of 4 rules for detection of Log4j exploitation and more general Java runtime exploitation.
We advise to import these rules (the import procedure is very simply done from the Admin -> Detection Rules -> Import section of EEI as described here).
These rules will also be included in the upcoming hotfix for EEI 1.6, but we are making them available to you:
Possible Log4Shell (CVE-2021-44228) exploitation [D0532a] Possible Log4Shell (CVE-2021-44228) exploitation [D0532b] Potential Java Runtime exploitation [E0461] Java Runtime executing suspicious script/command interpreter [E0462] The first two rules are designed to detect the exploit itself so the false positives count should be absolutely minimal. However, these rules are using an experimental feature of EEI which is not currently fully supported, so the detection may not work in 100% of cases. E.g. when there is a detection already reported on the network layer, rule in EEI will not be triggered (but in this case you should have detection from at least one source and protection is in place). Because of the way how the feature is implemented it is more reliable when executed as re-run task for a retrospective threat hunt.
The last two rules are focused on more general types of cases, general exploitation of Java Runtime i.e. not only by CVE-2021-44228. That means that those rules may generate occasional false positives for the cases when some legitimate Java application is executing system components which may indicate an attacker's activity. We have tested these rules to not have an excess number of false positives, but in case you will observe unusual amount of FPs in your environments - please report them back to us.
The rule pack itself can be found here.
Thank you.

If you are seeing fewer systems in your Protect console compared to your total licenses in use, it usually means that you either licensed some devices which are not managed, or you deleted managed devices without revoking their license.
In such cases you can login to your ESET Business Account and see which devices are using each license. I tend to sort them by last communication as often the ones offline for longer are some decommissioned devices we totally forgot about, but this occupy a license. In the same portal you can revoke the licenses from such devices which reduces your used license count.

No, you can upgrade straight away. The only issue is in our internal reporting mechanism, when it shows different "latest" version for applications previously upgraded / installed via "software install task" and different versions for applications upgraded via "micro PCU / Auto Updates" functionality. 

Thank Martin . it was Windows update which is stopping the agent or security update. i pushed the windows update so no issue now 
thank Million

Would it be possible to provide more details, especially failure reason as shown in the console? There should be localized error message, but also "trace" message which might provide more details.

In case both upgrade do fail, my best guess would be that:
there is a problem with connectivity to ESET repository servers (repository.eset.com) or there is some generic problem, for example another installation is running, OS requires restart due to performed OS update, or maybe there is not enough disk space But regardless of that, there are multiple possibilities how to upgrade those applications, especially in case you have access to the device - for example using standalone installers that can be downloaded from ESET web page, but also using various installers that can be created in the ESET PROTECT console.