dylanm

Description: Enable more advanced configuration and control scenarios for administrators via the command line.
1. Add eShell to Endpoint software.
Details: Adding the text based interface to the Endpoint client software will allow administrators to script the product and remotely access and configure the product without interrupting end user activities.
2. Add WMI classes for interacting (reading/writing settings and configurations) to security products.
Details: Expand upon the existing WMI support by allowing clients to configure security products using WMI/CIM interfaces.
3. Add a powershell module to security products.
Details: Tools that would further allow for configuring, testing, troubleshooting and working with the security products.  A powershell module would complement the existing eshell tool and would further enable advanced administration with the tools administrators are using. WMI tooling would allow for other tools to work with security products outside of the small handful of RMM integrations.
----------
Description: Make ecmd more useful.
Add a list/help parameter to ecmd. Something to list all the available commands. For example: -h --help /? /help /list /listcmds Add a reset configuration parameter. ecmd /resetcfg to reset the product to it's default configuration. Maybe add a parameter to get the default config as an xml file. Something like ecmd /getdefaultcfg <filename.xml>. ----------
Description: Add profile selection to ecls or add a new command line scanner that uses profiles and outputs to the application's log.
Details: If adding eShell doesn't get added to Endpoint, add a "profile" parameter to the ESET command line scanner program so that users don't have to try to configure the command line scanner to emulate a predefined scanning profile.
Alternatively a new command line scanner that simplifies the ecls experience but also fits nicely with remote management would be nice.  Currently ecls has options for specifying where to quarantine/log/load modules which is all very advanced and most people don't need. I think a scanner that uses the same profiles and logs as the main application would be a lot more friendly to end users and administrators. 
Example:
> eclods.exe ESET Command Line On-Demand Scanner Usage: eclods [SCAN PROFILE] [OPTIONS..] FILES.. [/exclude] FILES.. Scan Profiles: Profile names should be quoted. Alternatively spaces can be replaced with underscores ( _ ) or dashes ( - ). Smart scan The Smart scan profile uses Smart Optimization caching, which excludes files that were previously found to be clean. Context-Menu scan You can start an on-demand scan of any file from the context menu. The Context menu scan profile allows you to define a scan configuration that will be used when you trigger the scan this way. (default) In-depth scan The In-depth scan profile does not use Smart optimization by default, so no files are excluded from scanning using this profile. Computer scan This is the default profile used in the standard computer scan in eGUI. Custom scan profile names can also be specified. Create custom scan profiles in the product graphical user interface. Options: /subdir scan subfolders (default) /no-subdir do not scan subfolders /log-file=FILE log output to FILE /log-rewrite overwrite output file (default - append) /log-console log output to console (default) /quiet do not output to console Files: If no files are specified the profile's predefined targets will be used.  

The Endpoint firewall has some pretty good features when it comes to zones/profiles/rule matching. It would be a great addition to the Windows Server products since the Windows firewall falls short for advanced scenarios such as multi-homed machines.
I would use it for servers, even if it came in a separate installer, with a giant hazard label that said it wasn't stable enough for servers, and was entirely unsupported by ESET.

Description: Policy settings reverse-lookup
Detail: The ability in SMC/Endpoint Security to see which policy is responsible for which setting in effect on the computer.
Basically something like a GPRESULT report available for diagnosing Active Directory Group Policy Objects's effects.
A very simple example of that is shown here: https://4sysops.com/wp-content/uploads/2012/02/gpresult.exe-HTML-output.png

Description : Default "Preserver last access timestamp" to enabled/on.
Detail: There is little to no use in having last access timestamps of files be set to the last antivirus scan time, it provides us with no useful information while increasing disk utilization during scans. Furthermore having ESET overwrite last access times even removes useful information on when a file (like a document) was last accessed for real work.
I appreciate that ESET offers an option to not overwrite last access times of scanned files, but this option should default to On, while currently it defaults to Off.
What I don't know is: does enabling this option decrease disk utilization by System not having to write the timestamps to begin with, or does it even increase utilization by having to write the timestamps twice (first ESET scan and then restore to original)?

I understand the spinning platter situation, but modern systems don't use HDDs for system drives anymore. And even then, scanning network shares on my HDD based NAS is faster when done by multi-threaded AV products.
All of my own and my customers' computers use SSDs for years already. Defender peaks at over 2500 mb/s during on-demand scans running 24 threads/files in parallel, meanwhile ESET is chugging along one file at a time. This should be brought up to more modern standards rather sooner than later.
Furthermore large compressed archive files should be handled by multiple threads, too, especially for the uncompression part of the operation.