Jump to content

neilmartin83

Members
  • Content Count

    8
  • Joined

  • Last visited

Profile Information

  • Location
    U.K.

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. neilmartin83

    Future changes to ESET Endpoint programs

    Heya @Nathan Fishback, 6.7.600 is out now and fixes the TCC stuff as well as kernel panics and other things. Glad the blog post helped you out!
  2. Hi @alvinbridges, Thank you! Activation started working again - it was an issue at ESET's end. However, I did notice occasionally the installer with token applied using the add_token tool wouldn't activate for some reason, so built a way to remediate using Jamf. If you're using Jamf, this might be useful: I have the following Extension Attribute that returns the activation state: https://github.com/neilmartin83/Jamf-Pro-Extension-Attributes/blob/master/ESET Endpoint Antivirus - Activation Status.xml I have a Smart Group called "WARNING - ESET Endpoint Antivirus - Not Activated" with the criteria "ESET Endpoint Antivirus - Activation Status" "is" "Unactivated" I have a Policy scoped to the above Smart Group, set to run at Recurring check-in, Ongoing frequency. It runs a script that does the following: #!/bin/bash "/Applications/ESET Endpoint Antivirus.app/Contents/MacOS/esets_daemon" --wait-respond --activate key=$4 sleep 60 exit 0 $4 is a parameter for the serial number which I specify in the policy Script payload, rather than hard-coding it in the script itself (although you could put it in the script if you like - I just don't like hard-coding this sensitive/confidential things in scripts). After it runs the script, it performs an Inventory Update. Hope this helps.
  3. neilmartin83

    EES 6.7.500 Crashes Macs

    Just to chime in - I've noticed kernel panics with ESET Endpoint Antivirus on macOS 10.13.6, specifically when working with DMG disk image files (part of my job involves writing automated processes that manipulate them and that's when I noticed it). I also had one on a test client I was deploying software to via Jamf - the software was delivered as a DMG (which is unusual for me/my environment - most of the time I deploy PKGs so that would explain why I didn't notice any issues sooner/more frequently). Since deploying it to our fleet of 500 Macs, I've only had one user report this issue but it wasn't clear what he was doing at the time (he said he was checking email). Since installing the 6.7.575 beta on my Mac running a process that does a lot with DMGs, the kernel panics have stopped for me. Really looking forward to the January update!
  4. Just to report back, clients are activating again - thank you for your help!
  5. Hi @MichalJ, Thank you very much for your reply - I've sent you a private message with those details you requested. Please let me know if you need any further information. Kind regards, Neil.
  6. Things were going so well then I spoke too soon... I've started seeing serious activation issues since Friday (where there were none before) - wondering if anyone else has? Clients are appearing to activate properly via the installer package with token applied, using the command line method via esets_daemon or via entering the code/logging into our EBA account in the GUI. An activation record shows up for the client in EBA, but the client is reporting back that it's unactivated. I'm basically seeing this on every client I'm trying to activate now (over 20) including a VM I've been testing with at home, so I'm pretty sure it's not network related (i.e. proxy/firewall - we don't use a proxy at work anyhow). I've tried deactivating a problem client in EBA then re-activating it and that hasn't helped. The client re-appears in EBA though as expected, and the GUI/esets_daemon reports that the initial activation is actually okay, but doesn't actually activate. This is after successfully installing/activating it earlier in the week on approx 40 Macs that are showing no issues. I'm going to give support a shout soon but was wondering if anyone here has also seen this? Perhaps it's an issue with our specific EBA account? We've got nearly 500 Macs and I'm still at the "evaluation" stage for ESET - I need to pass on my recommendations as to whether we'll adopt it (following the discontinuation of SCEP) or go for something else, so this isn't favouring too well right now...
  7. In case any folks are interested, I've just published this: https://soundmacguy.wordpress.com/2018/12/04/hello-eset-endpoint-antivirus-deployment-management-and-migrating-from-scep/ 🙂
  8. Hi DJD, I'm in the same boat at you - migrating from Microsoft SCEP - it's disappointing to see a lack of documentation and support around deploying and managing this on macOS but as always, the community has got your back! After some conversations with other helpful members of the MacAdmins Slack in #endpoint_security we've worked out how to get ESET AntiVirus configured in via the command line - both the system level settings and user-specific GUI stuff. This is all still fresh and it's the weekend but I will write this up fully soon, like I did for SCEP at my blog https://soundmacguy.wordpress.com - here's the short of it: For system level settings: Set up ESET how you need it in the GUI - scan options, disable the email/web modules etc. Then export your settings as a file via the menu icon --> Setup --> Import/export settings. Then you can use the command line esets_daemon to import them (you need to specify the full path to esets_daemon of course - I've omitted it for simplicity here): esets_daemon --import-settings /path/to/settings/file You should kill the GUI and daemon as part of this process then re-load them to avoid user nags, e.g: killall esets_gui launchctl unload /Library/LaunchDaemons/com.eset.esets_daemon.plist esets_daemon --import-settings /path/to/settings/file launchctl load /Library/LaunchDaemons/com.eset.esets_daemon.plist Then restart or log out/in to bring the GUI back - or you can add the necessary commands to do that in a script, but this might vary depending on your management tools - I would work out the username of the logged in user then run an open command on the ESET application in their context, myself - a bit beyond the scope of this post. What's slightly annoying about this is you can't change settings in a granular, programatic way - it's just the whole file's worth or nothing. Maybe ESET support can offer some guidance? For user level (GUI) settings: You'll notice that the settings file doesn't account for GUI preferences that are user specific (everything under Preferences --> User --> Interface/Alerts and Notifications). If you've turned off the web and email modules, you'll see nags about that too which are suppressed with those user level preferences - definitely something we don't want! Anyway, those are stored in the file ~/.esets/gui.cfg and you can modify those with the old esets_set command, much in the same way as you did with scep_set. You can apply individual settings to it with esets_set, or just capture that file and re-import it, e.g: esets_set --apply=/path/to/exported/gui.cfg --cfg=/Users/username/.esets/gui.cfg This has to be run in the current logged in user's context (i.e. via a Launch Agent, or with something like Outset, or appending sudo -u username to the commands if running at root level with Jamf, it depends on your environment) and the --cfg flag needs to have the full path to the user's home directory - ~ didn't work in my testing. That's easy enough via a script - e.g #!/bin/bash loggedInUser=$( scutil <<< "show State:/Users/ConsoleUser" | awk -F': ' '/[[:space:]]+Name[[:space:]]:/ { if ( $2 != "loginwindow" ) { print $2 }}' ) killall esets_gui "/Applications/ESET Endpoint Antivirus.app/Contents/MacOS/esets_set" --apply=/path/to/exported/gui.cfg --cfg=/Users/"$loggedInUser"/.esets/gui.cfg open "/Applications/ESET Endpoint Antivirus.app" I haven't tested the above example but it should work. This is basically identical to how you'd do it in SCEP and I have a detailed post about that here: https://soundmacguy.wordpress.com/2017/11/19/managing-microsoft-system-center-endpoint-protection-scep-part-3/ For proper management of the those user GUI settings I'm looking to replace ESET's Launch Agent with my own script that will set the preferences then open the GUI when users log in - that'll make sure they revert back at each login in case users change things. It'll also avoid the need to kill the process first (except during installation/deployment in the first place - that's another piece of the puzzle I'm working on but it should be solvable). ESET - it would be really great to have some administrator-level documentation on the esets_set and esets_daemon commands please (hint - the ESET Linux documentation and manpages are good here - maybe we could have manpages for the macOS version too?) - we've basically had to dig in and work all this out for ourselves. 🙂 An interesting thing I noticed was that if you install ESET on top of SCEP, it'll handle the uninstall of SCEP as well as pick up its settings - both GUI (for the logged in user if present, taking root ownership of ~/.esets - not good!) and system level stuff. Last nugget of goodness - you can grab loads of useful information with esets_daemon --status I'm working on a few Jamf Extension Attributes to pull things like the definitions versions/dates, real-time protection status etc from it (I did this with SCEP but tended to scrape files instead - I like this better but didn't discover scep_daemon until afterwards and never got around to it...) - it's quite straightforward. I'm sure other management tools could leverage it as well. Hope this helps!
×