MartinK

Could you please provide more details of, especially: what are the changes you are doing on the policy before reboot - i.e. do you just unassigns it from all targets? Or you change target from group "All" to some other? what was the initial version of ESET PROTECT you actually deployed? Asking as there might be different behavior based on whether you already had ESET PROTECT deployed when this functionality was introduced (and communicated via specific dialog) or it was enabled to automatically during initial deployment of ESET PROTECT More details will helps us to check whether this behavior is expected or not. But regardless of that, ESET PROTECT documentation recommends to create "disabling" policy which will overwrite the global one to be sure auto-updates are disabled or re-configured on specific devices (https://support.eset.com/en/kb8147-opt-out-from-auto-updates-in-eset-protect-and-eset-protect-cloud)

We have encountered this issue recently. Could you please confirm this error happens when you are in "Create client task" wizard and try to switch type of the task (combo box with type of tasks)? Solution in this case is to avoid this kind of switching, i.e. either start generic client task wizard and select proper task type or use flow which preselects proper task type from the start.

Unfortunately direct downgrade is not possible. In this case, only possibility (without any guarantees as this scenario is not tested nor supported) might be migration (https://help.eset.com/protect_install/10.0/en-US/migration_procedures.html) as in case of switching DB types - but it involves new installation (with clear database) and manual migration of key objects so that at least connectivity of ESET Management Agents can be established - this includes especially migration of certificates in correct order. But be aware this might result in a state when connectivity of AGENT might not be possible to recover if steps are to be made in wrong order, or any other issues is found.

There are technically only two possibilities for deployment of ESET Management Agent on Linux as of now: [recommended]: Create script-based live installer (https://help.eset.com/protect_cloud/en-US/agent_live_installer.html) and run script on target device. Script is non-interactive and there are not even parameter required for it to download, configure and install ESET Management Agent. Use stand-alone ESET Management Agent installer, which is also shell script, but this mechanisms requires parameters to be provided and thus not so easy for deployment. In case you meant that live-installer script is not suitable for automation, could you possibly provide more details?

Such reports are available directly in the console, i.e. you have to go to client details and visit respective tab, which should show history of request for specific device (Show Details > Logs). Unfortunately this feature is not suitable for mass collection of logs but rather for individual diagnostic due to it's impact on resources.

Could you please elaborate more on those permissions problems? In case installer was not able to connect to database, it should not have done any modification - that would mean that re-execution of installer or it's repair should resolve database issues and upgrade its schema and data. But regardless of that, I would recommend to open support ticket if not done so already, as this might require more detailed analysis or guidance.

We would need more details for clarification before making any security-related decisions, but: Application hosted by Apache Tomcat, i.e. our webconsole deployed there is not accessed by any other service or component - i.e. you can change port and block any communication you wish. Impact on users will be inaccessible console via browser when accessing from blocked location ESET Push Notification Service indeed uses port 443 as an fallback, but this is service hosted by ESET itself, i.e. it just means that our components (like ESET PROTECT Server and Agent) are connecting to epns.eset.com:443 - so in case you are blocking only incoming connection to port 443, this should not be impacted. In case you are hosting ESET PROTECT (on-premise variant) in cloud, but your managed devices are located outside, crucial is to enable communication to port 2222 (if not changed), i.e. communication between ESET Management Agent and your ESET PROTECT Server instance. Port 2223 does not need to be accessible from outside, especially in case you are not using so called "Server assisted installation" of AGENTs. Also note that MDM management requires more ports to be opened.

There should be no problem with Apache Tomcat 7 as distributed in ESET PROTECT Appliance, if not very old version is used - in this case, we do support appliance as a whole. From provided logs it seems that there was an problem with communication between Tomcat and ESET PROTECT service, more specifically with TLS communication. For PROTECT 10.0 release, older TLS algorithhms/protocols were dropped (hardening, security-related), and it might have happened, that there was no overlap and thus components were not able to communicate. In case original appliance was deployed long time ago, it might have happened that Apache Tomcat configuration is no longer compatible, or there were some custom modifications made? Problems with Tomcat configuration might be mitigated by upgrading PROTECT via migration to new appliance, as is recommended by documentation = in this scenario, various system-based settings and configuration files are also updated, as oppose to in-product upgrade, where only ESET components are upgraded.

Unfortunately this specific scenarios are not documented, but there should be multiple ways how to deploy ESET Management Agent silently (i.e. preconfigured), and it mostly depends on mechanisms and capabilities of used solution. One can use: Create all-on-one package installer containing only ESET Management Agent - as an result, deployment of one executable (EXE) file is required in this case, witch specific commandline parameter to perform silent installation Create script-based live installer (BAT) in the console. Script does not require any parameters. Use so called GPO script mechanisms - in this case, MSI deployment is used, where parameters to the installer are provided as an external/separate configuration file which has to be copied to target machine side-by-side with standalone MSI installer of ESET Management Agent Use command-line based installation of ESET Management Agent using it's MSI installer. This requires to prepare command line parameters, which can be easily extracted from previously mentioned GPO installer configuration file.

Hi. Could you please provide trace.log of ESET Management Agent from affected device? It is hard to guess, but symptomps indicate that there is a problem with WMI on the device as most of the missing details are fetched using this mechanisms. If so, it is quite a common issue when sometimes it somehow stops working in Windows, and there are multiple guides how to fix this system components.

I will split it into two parts: ESET Management Agents has a grace period of a few weeks since release of lat version was done. This happened around 2 weeks ago, so AGENTs should slowly start to update itself. Regarding security products, auto-updates are not enabled yet to my knowledge, as there has been an hotfix release very recently to target issues that prevented global deployment.

Hi. For now, I would recommend to just stay on versions that do work for you. Indication was added to notify especially of "Windows" users which tend to use old and unmaintained versions of those components. We will probably have to target this in next release and possibly modify communication in a way that it is supposed to recommend specific component versions for the future. Regarding Java versions, officially only LTS versions are supported, as other versions are very short-living and tend to introduce breaking changes. We do expect that version 17 will be supported by ESET PROTECT for a longer time. But as of now, from technical perspective, console is still compatible with v8 (but this will probably change in near future).

Could you please provide us more details (trace logs from ESET PROTECT) via private message? It might indicate some database-related issue, possibly triggered by upgrade.

Please check following article: https://support.eset.com/en/kb6745-how-to-re-deploy-eset-management-agent-over-an-existing-password-protected-agent. It mentions what msiexec parameter is used to provide password to installer.

Yes, limit is considered as soft and only non-critical logs are counted. This means that all management data downloaded from ESET PROTECT Server and also high-severity logs uploaded from AGENT are not limited by this setting. So limit is mostly to prevent really excessive use of data, but there is no guarantee as in case of some outbreak it might happen that AGENT will attempt to upload such data to ESETE PROTECT for futher processing (notifications, etc.).

Also not there are some mechanisms that might wake-up client automatically, which would make it seems like instant application of settings - but this behavior is not guaranteed and it depends on various factors, as is size of environment, etc.

Those are actually two different configuration parameters: CRON devines when or how often will be task executed on client device Throttling defines limits for task execution, i.e. to prevent too often execution. It mostly makes sens for other then CRON triggers, i.e. for example execution based on dynamic group might result in unexpected number of executions. In case of software installation task, scheduling based on CRON should be sufficient, or ASAP execution with random delay might be also easier, in case there is no need for some specific limits, like execution only outside of business hours, etc. In case you consider CRON to be more suitable, I would recommend to check our special "R" character extension to it, which might help with randomization (see documentation: https://help.eset.com/protect_admin/90/en-US/cron_expression.html), as it is not possible to limit based on state of other devices, i.e. each device will be executing task independently. But with "R" you can statistically distribute execution in an interval. For example instead of splitting devices by specific hour of execution, you can use "R" which will randomize specific hour on device.

Maybe not helpful in this case, but when you create ASAP task on some parent/All group, and configure it in a way it has no expiration, it should executed this task only once, when such device is created in this group - so technically it should cover this case. It won't omit devices where this application is already installed in a moment of first connection to console, but my understanding is that it is acceptable for those systems.

Could you please provide more details of this environment and method you used for deployment? Asking as it seems to be related to communication between browser and console, so it might be related to configuration of Apache Tomcat, and also other network related components in between - for example load balancers, etc. Also we have experienced problems in environments, where clients do have multiple IP addresses which were changed randomly between requests - but regardless of that, I would recommend to open standard support ticket and collect at lest HAR logs from browser communication, which should help diagnose this communication problem.

Behavior of coloring is defined in this section for this report template: but it depends of what kind of data is to be rendered, as some coloring schemas might be used only with specific data values (for example severity-based coloring). Regarding listing of the same device multiple times, it is most probably result of report definition, which probably lists device with each scan times reported. We do collect entry for each scan reported by product, so showing only latest one might require more complex report definition or proper ordering. Also note, that the original issue with wrong last scan time was reported some time ago and is prepared for next service release. As I proposed, it was indeed problem with ordering, where not last, but oldest scan time was shown...

Could you be please more specific of what you mean by edit of widget? Color schema is defined in configuration of respective report template, so it is possible that once edited, it is somehow overridden with incorrect property. If possible, some reproduction steps would be helpful so that it can be reported and possibly resolved for upcoming release.

Thanks for hints. We are aware of this limitation but we do preferred bash as it was working (at least with explicit use) on all supported macOS versions, but we will have to look whether we can possibly make it work with both interpreters or completely switch to zsh as more and more systems are including it. And I will add one note regarding plistbuddy -> it was used in older releases, but it had to be abandoned as this tool had an issues with longer strings (for example certificates that might have exceeded 4KB size).

Most common issue in this case is ESET PROTEC's certificate. In default configuration, it contains IP addresses and hostnames known during installation (can be seen in console as "Host"). In case this certificate does not contain hostname you are using for clients, those will reject communication. If this is the issue, solution would be to create new PROTECT Server certificate, with newly defined hostname. If such certificate would be signed with original certificate authority, change would be transparent for clients.

Thanks for reporting. It will be forwarded for further analysis, but it definitely seems to be wrong. I would expect it reports last recorded scan instead of latest as similar issue was present long time ago also in client details view.

For the original problem, I would recommend to check older topic: In case communication stopped just suddently, it might be related to secure connection certificates (= expired certificate) or maybe there was just an update of the operating system hosting AD and protocol used previously is no longer available. But this is hard to diagnose without more details. In case of upgrade issues, if possible, please provide us at least ESMC's Server trace.log from moment then service cannot be stopped. There is a possiblity stop is just slow and is not finished in time for the installer to work properly. From logs we should at least see in what moments it the shutdown process stuck. Also is it possible to stop ESMC Server manually? If so, stopping it manually before executing upgrade might help to mitigate this issue.