System Center Endpoint Protection For Mac

Related services: Endpoint Protection, Certified Desktop, CrowdStrike Endpoint Protection

Microsoft will end support for all Mac versions of System Center Endpoint Protection (SCEP) on Monday, December 31, 2018. If you're currently using any version of SCEP for Mac, plan to migrate to a replacement endpoint protection product for Mac clients.

Johns Hopkins System Center Endpoint Protection (SCEP - A Microsoft Product). On behalf of the Johns Hopkins Institutions, [email protected] offers Microsoft System Center Endpoint Protection, available for Windows, Mac, and Linux Operating Systems.The software is free for any Johns Hopkins. The following information describes the supported versions of System Center 2012 Configuration Manager SP1 and System Center 2012 Endpoint Protection SP1 running on various Macintosh and Linux/UNIX operating systems. System Center 2012 Configuration Manager SP1 For Mac-based clients.

Cornell policy requires all university-owned computers to use antivirus protection, and strongly recommends the same for any computer used by a member of the Cornell community. Local IT support administrators who have onboarded with Certified Desktop can deploy CrowdStrike for Mac, providing antivirus scanning and endpoint malware protection and response. Learn more about antivirus options for Mac.

If you have any questions, contact your local technical support provider or email [email protected]

System center endpoint protection client

In Part 1, we looked at how it was possible to configure pretty much anything in SCEP with the venerable scep_set command. Here, we’re going to focus on something else. It’s often in an organisation’s information security policy to ascertain whether the devices you manage are “compliant” with a set benchmark, whatever it may be.

For many, that benchmark may include the need for an antivirus/malware solution that has up-to-date definitions. We might also want to know how many “infections” each client has encountered. As systems administrators, the expectation is that we should be able to know this stuff and report on it. Turning to SCEP, if we look in the user interface of the application itself, it does indeed give us a window into its activity logs for each Mac, individually, but again, when it comes to integration with management tools that could report on the entire fleet, it appears we’re stuck.

Or are we?

What if we could dig into SCEP’s actual log files and pull out the information we need? As it turns out, SCEP’s log files are just plain text, so let’s have some fun with them!

Note that for readability I have removed the paths to the log files in the example code snippets below, so be sure to add them back or else you’ll be scraping files that don’t exist!

What version of definitions do I have now?

Check out this bad boy:

This file contains a wealth of information but if you look in the [CONTINUOUS_ENGINE1] section, there’s an entry, versionid. With a little creative use of grep and cut we can isolate this:

In my case, at the time of writing, this returns the number 16135. Check out this KB on ESET’s website (remember, SCEP for Mac is rebadged ESET!). They update it regularly with the latest definitions version number:

What do you know, it matches!

Microsoft system center endpoint protection for macFor

Here is a Jamf Pro Extension Attribute that returns this information.

When was the last time SCEP updated its definitions?

Look at this little gem:


If you look inside this file, some entries stick out, particularly LastUpdate. Let’s scrape it out with some more grep and cut goodness:

System Center 2012 Endpoint Protection アンインストール Mac

Which gives us (at the time of writing) 1506316156. That’s a date but not as we know it – the format is UNIX time. We can convert this to something human (and Jamf Pro in my case) readable with the date command:

System Center Endpoint Protection For Mac

Then we get 2017-09-25 06:09:16 – sweet!

Put it together and here’s what you’d use to return the date at which SCEP last updated its definitions, in the format we want:

The above date’s format is perfect for a Jamf Pro Extension Attribute which returns the “Date” Data Type. Click here to download such an Extension Attribute! Because it outputs a date, you can use Smart Group criteria such as “less than x days ago” with it. Here’s an example Smart Group you might use to report on whether Macs have the current version of SCEP with a recently updated set of definitions (Application Title is System Center Endpoint This might be used as part of a wider compliance reporting mechanism.

What have the on access and on demand scanners been up to?

SCEP logs statistics for its on demand and on access scanning in the following files, which again can be leveraged to provide specific information:

On demand log:

On access (realtime scanner) log:

These log files have an identical structure, so any methods you use to scrape one will work on the other. Here’s the contents:

If you wanted to report on the number files cleaned by the on access scanner, you could use the following in a bash script:

To report a different statistic, in the grep part above, you’d just replace cleaned with another item in the log, e.g. infected. To report on the on demand scanner, just change stats.onaccess to stats.ondemand above so you’re cat-ing the correct log file (and don’t forget to include the full path which I have removed here to make the code more readable!). Cleaned files are those which SCEP found to be infected and subsequently cleaned. Files are reported as infected if SCEP could not cleanthem.

Some examples of Jamf Pro Extension Attributes:

System Center Endpoint Protection Mac Os

As above, those EA’s could easily be modified to report on any statistic in either of SCEP’s on access or on demand logs.

System Center Endpoint Protection For Mac

My inspiration for writing this stuff has to come from somewhere. I’d like to point to this thread on Jamf Nation as it got me going in the right direction, with specific thanks to Nicole Deal (@ndeal), Kenneth Edgar (@kedgar) and Alan Trewartha (@alan.trewartha).