No, not the certificate thing. Microsoft System Center Endpoint Protection for macOS and Linux, as announced at Microsoft’s Blog. There were rumours of its impending demise on Twitter back in March but nothing concrete from Microsoft until now.

So, no more support after the end of 2018 and definition updates may stop any time after that. There is the mention that you might be able to get ESET Endpoint Security for Mac if you contact your Microsoft TAM. The cost implications, or what it means to “qualify” are unclear.

As far as I know, ESET Endpoint Security for Mac uses a command line tool esets_set which is functionally on par with scep_set. That means my blog posts for managing SCEP (Part 1, Part 2, Part 3, and More Reporting) would probably be relevant for it.

Linux is left with no migration path – so if you manage SCEP on that platform, you’re on your own.

Goodbye SCEP, it was nice knowing you!


Published by n.martin

Managing 450-odd Macs at a university, innit.

Join the Conversation


  1. Except that the version of ESET that they offer to SCEP orphans doesn’t pay any attention to the esets_set configuration.
    Firstly, the esets_set command line tool writes to a file that doesn’t exist: /Library/Application Support/ESET/esets/etc/esets.cfg doesn’t exist by default. You can create it and esets_set will then write into the file.
    But it doesn’t do anything.
    ESET Endpoints uses: /Library/Application Support/ESET/esets/cache/data/settings.json
    And, yeah, it’s a json file, many pages long. And, best I can tell, has no configuration tool associated with it.


      1. I’ve posted this on the ESET forum (awaiting moderation) but here it is (sorry for the unformatted code snippets – WordPress comments…). I’ll write up a proper post soon once I’ve got my deployment fully tested. There is a light at the end of the tunnel and it’s not all doom and gloom…

        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 – 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


        loggedInUser=$( scutil <<< "show State:/Users/ConsoleUser" | awk -F': ' '/[[:space:]]+Name[[:space:]]:/ { if ( $2 != "loginwindow" ) { print $2 }}' )

        killall esets_gui

        "/Applications/ESET Endpoint" –apply=/path/to/exported/gui.cfg –cfg=/Users/"$loggedInUser"/.esets/gui.cfg

        open "/Applications/ESET Endpoint"
        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:

        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).

        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 any users pre-existing on the Mac, taking root ownership of the ~/.esets directory for each one, but not the gui.cfg file at least – not too good!) and system level stuff as well. The pre/postinstall scripts in the package were a really interesting treasure trove for finding this out.

        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!


Leave a comment

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: