apatheia

Yeah, it's nice, but it's also a shame they don't seem to have documented this anywhere.

So, I may have solved my problem in the short term. I haven't found the exact setting my original question referred to, but this may be a start... Digging around, I found a binary called esets_set, which is of particular interest if you are managing Endpoint products with ERA 6. ERA 6 doesn't have complete policy management yet, so this binary might useful for managing some settings that policy doesn't quite yet. In the terminal, ​/Applications/*ESET\ APPLICATION\ HERE*/Contents/MacOS/esets_set --help OR /Applications/.esets/Contents/MacOS/esets_set --help yields: Usage: esets_set [OPTIONS..] [COMMAND] ESET Endpoint Antivirus Configuration modifier Commands: --set='NAME=VALUE' set NAME=VALUE for given SECTION (or USERSPEC), or unset it if only NAME is given --create create given SECTION (or USERSPEC) --delete delete given SECTION (or USERSPEC) --last make USERSPEC the last one --backup=FILE back up configuration to FILE --apply=FILE apply configuration from FILE If no command is given, --set is assumed. Options: --cfg=FILE configuration file --section=SECTION operate on SECTION instead of "global" --user=USERSPEC operate on USERSPEC in SECTION Common options: -h, --help show help and quit -v, --version show version information and quit (C) 2015 ESET, spol. s r. o. To report issues, please visit hxxp://www.eset.com/support This is a start, but it not terribly helpful: it doesn't provide any parameter listings! So, back in the terminal, type strings /Applications/.esets/Contents/MacOS/esets_set to output printable strings from inside the binary. Some of the strings are parameters that this binary will accept. When attempting to set a parameter for the first time, it outputs the following error: Cannot open file /Library/Application Support/ESET/esets/etc/esets.cfg: No such file or directory It seems to want to place any global parameters in /Library/Application\ Support/ESET/esets/etc/esets.cfg by default. The problem is that this file doesn't exist. Creating it and setting parameters in this file don't seem to do anything either. So instead, you can target a cfg file that does exist: /Users/*USERNAME*/.esets/gui.cfg Adding the following lines to this file, for example, will do something that the ERA 6 policies can't do yet: [gui] dock_icon_enabled=no You could also type the following command to achieve a similar, but broken result. sudo /Applications/.esets/Contents/MacOS/esets_set --set='dock_enabled=no' --section=gui --cfg=/Users/*USERNAME*/.esets/gui.cfg This command yields the following result in /Users/*USERNAME*/.esets/gui.cfg [gui] dock_icon_enabled = no The extra spaces around the = sign render the setting inert. Removing the extra spaces will enforce the setting. Anyway, reboot the system and the example above will disable the dock icon from showing at sign in for the targeted user. Nice, but not great. Still working a way to target global preferences... By the way, this is all undocumented for the Mac as far as I can tell and there may be a reason for that. It could be they haven't gotten around to documenting this feature, OR its not finished yet (as the space parsing issue seems to suggest?). Anyone else have any luck with this approach?

Found 'em. The are a handful of binaries inside the the ESET application. Go to /Applications/*ESET\ APPLICATION\ HERE*/Contents/MacOS/ Inside you'll find Inspector esets_daemon esets_gui esets_mac esets_sci esets_ctl esets_esi esets_kac esets_scan esets_set The esets_scan binary is the one you are looking for. Type the following to see all of the parameters you can use with this binary (fix the path to include your application - don't forget to escape spaces with a leading \ . /Applications/*ESET\ APPLICATION\ HERE*/Contents/MacOS/esets_scan --help

Don't know your specific problem, but the attached are my notes for a working installation process for getting ERA 6 to function on CentOS 7 64-bit Minimal. I know it works because I just ran through it in my lab environment this morning. The domain join and LDAP lookup has not been documented completely yet, so maybe skip that part for now unless you know what you are doing. It doesn't include post installation steps, but this should get you started. YMMV. centos 7.x - era 6 scrubbed.pdf

*Bump*. Reviving this thread. I'd be interested in some command line parameters too for the Mac and Linux. Especially for settings that policies that ERA 6 doesn't cover.

Yeah, the sooner you all can flesh out the OS X and Linux policy support, the better. I've found it severely lacking. As for disabling it in the setup, I can't tell my users to "Go into the settings, click tab A and flip switch B to get result C". Ain't gonna happen. I don't mean to sound like an elitist IT guy, but some people just aren't capable of dealing with a settings window with out calling the help desk... Have to ask: you have a time frame for this (and any other new policy controls)? Any time you have a setting that defaults to notifying the user client-side, you must have policy to turn that stuff off. That's just management 101.

Ok, so is anyone else bothered by the fact that their users are being notified that the operating system is not up to date? Where I work, IT manages all system updates and deploys them through separate managed software update deployment system (we use Munki since we're an all OS X operation). It's confusing and annoying for our users, since they can't do anything about it anyway. Also, the notification includes a link to the App Store application, which in our case, is useless. Again, we use Munki and it's accompanying Managed Software Update application to managed all software patches, updates, deployments, everything. I would imagine that Windows shops also have other patch and application deployment mechanisms in use apart from the blessed Microsoft offerings, so my situation can't really be way out in left field, can it? Now, as far as I can tell, there is no policy option to turn off this client-side notification. So my question is this: when is ESET going to provide more robust and complete policy management for OS X and Linux systems? Or are they already and I'm missing something?

So, Marcos, I have a question for you: I'd also like a custom installer. Manually running the latest installer for Eset Endpoint Antivirus for OS X, I noticed the option to create a customized "Remote Install". This allows me to remove certain components (like Email protection - we only use web mail clients) from the resulting installation. It's just less to manage. Less is good I would love to see this type of custom install through ERA6 with installation parameters, which I believe are currently useful for Windows .msi installs only. Correct? So, I'm wondering this: is it ok to deploy this custom Remote install and the ERA6 agent (the shell script generated from ERA6 and modified to point to my own local repo URL) through my own package management system and then manage with ERA6? Or is this just a setup for issues later on? Let me know if I need to provide more details.

Here is an updated version of the walkthrough. Again, some areas are incomplete, but this one will at least install and configure a database that works. No guarantees that the steps below will work in your environment. With that said, you might find some of it useful for troubleshooting your own specific issues. See attached file in written in Markdown format. YMMV CEntOS 7.x - ERA 6 SCRUBBED.txt

I have ESET Remote Administrator Server and Agent installed and running on CentOS Linux release 7.0.1406 (Core) Minimal. All prerequisites are installed. The Remote Administrator Agent is also installed on the clients and can successfully contact the server. In the web console, the status of the clients is inconsistent. Some show the Remote Agent icon badge, others do not. Some show the badge for a time until, for example, the computer is moved to a static group, at which point the Remote Agent badge disappears, along with the associated computer information. For example, OS Type = Mac OS X is not displayed. Sometimes the IP address associated with the computer is displayed next to the host name, then it will disappear over time. The DNS environment is functioning correctly and has a functioning reverse lookup. Dynamic groups also do not appear to function properly. Assigning a policy to a dynamic group will occasionally work. That said, a computer that belongs to the dynamic group will pick up the policy, but never appear in the group when going to Computers > All > Windows computers. Also, computers with the Remote Agent installed often do not report items like OS, Platform, etc. Some do, and others don't. I've noticed that Windows 7 computers will eventually show this data in the web console, while Mac OS X computers never do. This may be why some of them do not appear in the dynamic groups. Again, even if a system has these items listed, it might still not appear in the dynamic group. For example, a computer might have OS Type = Microsoft Windows, but it does not appear in any dynamic Group that includes this parameter. If a computer eventually appears in a dynamic group, restarting the host server will cause the ERA web console to show empty dynamic groups at the next login. Please advise.

Is there a time delay between adding an agent reporting system information to ERA server and a system appearing in a given Dynamic group? If so, what is the time period and can it be shortened to expedite the testing period? I have an agent installed and functioning on the ERA server. OS information is reported correctly, but the system does not appear in the Linux dynamic group. Please advise. I can provide logs if needed.

In addition to the official documentation for installing ERA 6 on Linux (which you should read first), I expanded the official documentation with some of my own notes for building up a Linux-based installation of ERA 6. It's not complete, but it will get you further along than the official documentation does. Hopefully, this will be of use to someone else. No guarantees that the steps below will work in your environment. With that said, you might find some of it useful for troubleshooting your own specific issues. Process is attached as a clear text file formatted in Markdown. CEntOS_71_ERA6.txt