stevemaser

Is there an ETA on the next service release? We've been waiting for a fix for the "Restart Computer" issues for what feels like 6 months now...

I believe it's P8DQRXPVLP You should be able to run this command to get a list of the values: sqlite3 /var/db/SystemPolicyConfiguration/KextPolicy "SELECT developer_name,team_id,bundle_id,allowed from kext_policy"

OK -- we figured out how to do this. If anybody else is interested: Two preinstall steps: sudo killall esets_gui sudo launchctl unload /Library/LaunchDaemons/com.eset.esets_daemon.plist Install the application (in our case either Office 2016 or 2019) then two post-install steps: sudo launchctl load /Library/LaunchDaemons/com.eset.esets_daemon.plist open -a “/Applications/ESET Endpoint Antivirus.app” Not the best solution -- but Office installs are taking *at a minimum* 4 times longer with 6.7.900, so we had to do something...

This is related to my Office vs. 6.7.900 issue. Is there a command-line way to disable the Real-Time scanner and then another command to re-enable it? That would be a better (and faster) short-term solution we might be able to push out to our 8000+ system fleet to address the problem with 6.7.900

Yeah, I've already started that process, but wanted to know if this a "just us" thing or not.

Hey all... We just pushed out ESET A/V 6.7.900 to our fleet and Microsoft Office installations are now taking significantly longer (like going from 8 minutes to 30-60 minutes) Anybody else seeing similar?

Well, it seems to handle the uninstall properly, but doesn't seem to pick up any of the customized SCEP settings. So you still need to craft a comparable set of preferences and export/import that for ESET to be useful

Description: For the Mac version of ESET, the "alert" settings should be global settings and not per-user settings. Details: We are one of the orgs moving from SCEP to ESET for now and *not* using the ERA (as we would prefer not to have to spin up yet-another-server for this.) Apparently all the Preferences --> User --> Alerts and Notification settings are stored within a ~/.esets/gui.cfg file. This is a problem -- especially for the "Protection Statuses" Alerts. We need to be able to turn those off globally -- especially for computer labs where local student accounts are wiped from computers soon after they log out. We (as computer administrators) should be able to set these globally for all users without having to massage a file into each user account every time somebody new logs into the computer. It's nice to see that ESETs has more notifications than SCEP, but end users in a computer lab do not need to get an alert that "operating system is not up to date" (for example) when we control OS patch releases.

We ended up deploying without advanced heuristics because of one of the issues documented here: https://forum.eset.com/topic/4086-three-bugs-two-serious-with-docx-files-on-mac-os-x-server-eset-60140/ FWIW...

We have a ticket open with Microsoft about this behavior with SCEP 4.5.21.0 (since it's their branded version of ESET) -- as it seemingly only affects MS Word (at least the non-duplicate bugs do...) I did submit the above bugs to ESET support, but basically just got a "thanks. don't call us, we'll call you" response to these bugs -- which was a bit disheartening. ALSO -- FWIW -- I did try setting exclusions to .docx extensions -- but that made no difference (and I thought it would...) I can not exclude the path as that would vary from end-user to end-user.

Why all these issues are associated with .docx files -- is probably a good question for Microsoft. I tried a .doc file -- and could not reproduce any of the three problems (same with .xls/.xlsx and .ppt/.pptx files...) Whatever the problem is with Word, ESET is not handling these files correctly and causing deleting/hanging/degradation.

Full disclosure -- we are attempting to use Microsoft's SCEP 4.5.21.0 -- which is based on the ESET engine and discovered two bugs with it -- so we decided to check the current trial version of ESET to see if the two bugs are there -- and they are.... Using ESET 6.0.14.0 on Mac OSX 10.9.5 and 10.10.2 clients connecting to Mac OS X Server (both 10.9.5 and 10.10.2 server tested...) SERIOUS BUG 1 -- Default install of ESET will delete saved Word 2011 .docx files on server when connected to server via SMB To reproduce: 1) Default installation of ESET on Mac 10.9.5/10.10.2 client. 2) Client opens a .docx file (<filename.docx>) with Word 2011 (current version) on an OS X server share (problem seems limited to .docx files -- not .doc files or .xlsx/.pptx files...) 3) User attempts to save the file. A dialog box pops up that says "There has been a network or file permission error. The network connection may be lost. (<filename.docx)> 4) This results in the original file being renamed to "Word Work File _L3.tmp" and a saved file named "Word Work File L_1.tmp" -- but the original <filename.docx> -- is completely gone. WORKAROUND: In ESET, if the following default check box is *disabled*: Preferences --> Real-time Protection -- > Advanced Options --> Scan Options: Advanced Heuristics Then the user can open and save the .docx file without the original file being "deleted" and the two "Word Work File..."s created and left behind. SERIOUS BUG 2 -- Word will SPOD if the above is attempted, but the server connection is made via AFP instead of SMB. We attempted to reproduce the above bug on a 10.10.2 client by having the client connect to the server via AFP instead of SMB. This has worse results. In this case, the user goes to save the file, but the following happens: 1) A "Word Work File D_.tmp" file is created on the server. 2) Word goes into a SPOD -- and does not recover and must be force quit. Which seems to still leave something locked on the system as it requires a hard shutdown to restart. 3) After client restart, "Word Work File D_.tmp" on server is still flagged "in use" and can not be deleted by client. WORKAROUND -- have not determined if there is one short of turning the RTF *off*. Nor do I know if this is limited to .docx files (I just ran across this one right now while documenting the bug above...) BUG 3 (not as serious) -- Occasionally, server files can not be duplicated with default ESET settings (also when connected via SMB) To reproduce 1) Same default install of ESET, same clients, same server as above, but connecting via SCEP 2) User goes to a server folder containing a number of files. 3) User attempts to duplicate files on the server. (Simple command-d duplicate) 4) Occasionally, user will be unable to duplicate the file and the Finder shows a dialog box that says "The operation can't be completed because the item "<filename.docx>" is in use. WORKAROUND: subsequent attempts at duplicating the same file will work if the user tries again. or Disable: Preferences --> Real-time Protection -- > File Open None of these issues occur without ESET (or SCEP) installed. These are all pretty terrible bugs, frankly, and are easily reproducible... Is there anyone on the forum that can address any of these issues?

Is there a way to temporarily disable the Real Time File System Protection from the command line (and then reenable it?) sudo launchctl unload <something> for example? Thanks!

Our overall goal here is to be able to generate a report on multiple machines to see what viruses are being detected on each of them, but not having to parse a system.log file that would rotate every day (which is still doable, but...) We had hoped we could block of the logging to system.log and read the logs that the *application* is still displaying, but it seems not...

Yeah, those are not world-readable, unfortunately. It seems like those might be the files, though... But maybe not. I don't see the timestamps on anything change if I download "eicar.com"? We'd probably have to filter against the system.log file...