Creating an Endpoint Protection Alert using System Center Orchestrator

This post is obsolete and this process will no longer function. Please see Creating an Endpoint Protection Alert using PowerShell ( for a new method of providing this alert.

CM 2012 does not provide a built-in method for alerting administrators when a remediation action fails for Endpoint Protection. When remediation fails, the device is still considered infected. Even more of a concern is if the infection changes Endpoint Protection settings.

This is the first of a two part series that will go over how to create an alert so that administrators can be notified when remediation fails. This part goes through the first half of creating the run-book, and next week will be the second half, and the other run-book that is required.


In the Monitoring node on the CM 2012 console is a section for Endpoint Protection. If you expand this node, and select “System Center 2012 Endpoint Protection Status”, you can see a chart like this:

This chart shows you what is happening in almost real time. As you can see, I have four devices where remediation failed (ie the device is still infected) and one device where the malware modified the client settings. These are the machines we are focusing on.

By default, this chart updates every 20 minutes when Endpoint Protection summarization runs. You can set that value lower or higher by using the CM 2012 PowerShell cmdlets. Simply connect to CM 2012 using PowerShell (in the file menu of the console) and type:

Set-CMEndpointProtectionSummarizationSchedule -Interval <value> -UnitType <minutes, hours, or days>

To complete this runbook, your Orchestrator service account will need at least “Read-Only Analyst” in the CM 2012 console. This allows the service to execute WMI queries again CM 2012. If you want to do the query database step to grab the path of the infection, the Orchestrator service account will need “db_datareader” access to your CM 2012 database. You will also need to open port 1433 (TCP and UDP) from your Orchestrator runbook server to the server running the CM 2012 database. If you do not use the default SQL port, replace 1433 with the port number you use.

Preparing the System

For my process, I create a marker file that is the name of the device. I create this file in a share on the runbook server. You need to create this share before building the runbook. Creating the share is outside the scope of this article, but I do recommend hiding it (simply put a dollar sign ($) after the share name). Your Orchestrator service account will need Full Control rights for the share, and Read / Write / Modify NTFS rights to the folder containing the files.

When the runbook executes, it creates this file after sending the alert email. When the runbook executes again, it checks this directory for those files, and does not send another email if a file with the infected computer name exists. This is to prevent you from getting multiple emails for a single computer. I then have another runbook that runs that deletes these files once the computer is cleaned (more on that later).

Creating the Alert Runbook

Here is a picture of what your runbook will look like:

It looks complicated, but it’s actually quite simple. The items on the top line are the “essential” processes. These are what gathers the data and does the processing. The bottom line can be left out if you want. I will go through each one individually.

Find Computers with Remediation Errors

To get started, expand the “System” integration pack and drag a “Run .Net Script” activity into your workspace. Open it, click the “General” node, and give this step a name. I named mine “Find Computers with Remediation Errors”. Next, go back to the “Details” node, and set the language type to PowerShell. In the box, paste this code:

$a = @()

$epfailed = Get-WmiObject -ComputerName <FQDN of your CM 2012 server> –

namespace “root\sms\site_<3-digit CM 2012 site code>” -class SMS_CombinedDeviceResources |

where-object -FilterScript {$_.EPInfectionStatus -eq “4”}

foreach ($fail in $epfailed) {

$a += $fail.Name


This step creates an array of all devices where the EPInfectionStatus property is set to “4”. When a device infection status is set to four, it means that remediation has failed or the client settings have been modified by the infection.

Next, click on the “Published Data” node. Click the “Add” button, and fill the box in like this:

This publishes the list of devices to the next step. The variable name field is the value you assigned to the variable, and the name field is a common name for the variable.

Check to see if Computer has Alerted Already

Drag another “Run .Net Script” activity into your workspace. Open it, give it a name, and return to the Details node. Change the language type to PowerShell, and paste the following code into the script box:

$comps = “{Computer Name from “Find Computers with Remediation Errors”}”

$alerted = “No”

ForEach ($comp in $comps) {
If ((test-path \\<FDQN of server running marker share>\<share name>\EP\$comp) -eq $true) {
$alerted = “Yes” }

Delete the “{Computer Name from “Find Computers with Remediation Errors”}” part (leaving the outside quotes). In its place, right-click, go to “Subscribe”, and select “Published Data”. Select “Computer Name” from the box, and click ok. This inserts the variable. Remember this, as we will be doing this a lot through the rest of the article.

Now we need to publish some more data. Open the “Published Data” node again, select “Add”, and fill the box out like this:

This publishes the “alerted” variable to the next step, which tells the system there has already been an alert generated for this device.

Process Computer Data

Next, create another “Run .Net Script” activity. Open it, give it a name, and go to the “Details” node. Change the type to PowerShell. This the main activity in the runbook. It is what gathers all of the data needed to generate the alert email. Paste this code into the script box:

$comp = Get-WmiObject -ComputerName <FQDN of CM 2012 server> -namespace “root\sms\site_ <CM 2012 site code>” -class SMS_CombinedDeviceResources | Where-Object -FilterScript {$_.Name –
eq “{Computer Name from “Find Computers with Remediation Errors”}”}

ForEach ($infection in $comp) {

$compname = $infection.Name
$resourceid = $infection.ResourceID
$infectionname = $infection.EPLastThreatName
$sigversion = $infection.EPAntivirusSignatureLastVersion
If (($infection.EPAntispywareSignatureLastUpdateDateTime) -gt “1”) {$virdefupdate =

If (($infection.EPLastFullScanDateTimeEnd) -gt “1”) {$fullscan =

If (($infection.EPLastInfectionTime) -gt “1”) {$lastinf =

$usra = (Get-WmiObject -ComputerName  <FQDN of CM 2012 server> -namespace “root\sms\site_<CM2012 site code>” -class SMS_UserMachineRelationship | Where-Object -FilterScript {$_.ResourceName –
eq “{Computer Name from “Find Computers with Remediation Errors”}”}).UniqueUserName
ForEach ($usr in $usra) {

If ($usr -like “*”) {
$ = $usr
$usrname = $.replace(“\”,””) }

$ipa = (Get-WmiObject -ComputerName <FQDN of CM 2012 server> -namespace “root\sms\site_ <CM2012 site code>” -class SMS_R_System | Where-Object -FilterScript {$_.Name -eq “{Computer Name
from “Find Computers with Remediation Errors”}”}).IPAddresses
ForEach ($ip in $ipa) {

If ($ip -like “.*”) {
$ippub += $ip }

In this step, we are running three WMI queries against the CM 2012 server. The first pulls all relevant information from the SMS_CombinedDeviceResourses class. It is pulling the computer name, the resource ID of the infected client, the name of the infection, the anti-virus definition file version, the date and time of the last definition update, the date and time of the last full scan, and the date and time that the device was infected. All of this data, except for the resource ID, will be used in the email. We will need the resource ID for the query database step. All of the date and time variables are channeled through IF statements because the “ConvertToDateTime” action will error the PowerShell statement if the field is blank. I am not sure at this point why the field would be blank, but I have noticed it in some cases.

The second WMI query is pulling the primary user of the machine. It is also tunneled through an IF statement, because that value can also be a local user. This step pulls local users out, and only sends through the domain user. This is important in the “Get User” step that is coming up. Replace <domain name> with your domain name.

Finally, the third WMI query is pulling the IP address(es). This is piped through an IF statement also to strip off non-company IP addresses that get stored in CM 2012. Replace <first two octets of IP range> with the first two sets of numbers from your organization’s IP range. Make sure you keep the “.*” as is. It would appear that this section would form an array if a computer has a wired and wireless card. Because we do not have $ippub = @(), the array is never actually formed. If you actually type this into PowerShell and view the output, it will look similar to “”. This is the purpose of the next item. We will split these into two sections. It is important that this step is not an array, because Orchestrator recognizes an array and splits it into separate jobs, which would create two emails for one computer. This process (not adding $ippub = @()), essentially “flattens” the array.

Now we need to set up our published data. If you go to the “Published Data”, set it up like this using the same method from above:

To finish this action, we need to modify the connection between “Check to see if computer has already alerted” and “Process Computer Data”. If you double-click on the arrow connecting the two, you get a box like this:

If you click on “Check to see if computer has alerted already”, you select “alerted”. Once you do that, the statement changes so that it will only proceed if “alerted” equals some value. You specify this value by clicking on “value”. Put a value of No in this box. Once complete, it should look like this:

This concludes this part of the series. Next week we will talk about the second half of this runbook, and the runbook that removes the markers when created.



Contact Us

On Key

More Posts

WME Security Briefing 27 May 2024

Kinsing Hacker Group Exploits Docker Vulnerabilities Overview Recent investigations have shown that the hacker group Kinsing is actively exploiting Docker vulnerabilities to gain unauthorized access to systems. The modified hacker group targets misconfigured Docker API ports deployed with cryptocurrency mining malware.

Read More »
WME Cybersecurity Briefings No. 010
Cyber Security

WME Security Briefing 20 May 2024

Advanced Persistent Threats: North Korean Hackers Launch Golang Malware Overview A new malware strain, called Titan Stealer, is currently actively circulating in the threat landscape, targeting a variety of personal data and linked to North Korean state-sponsored cyber espionage

Read More »
WME Cybersecurity Briefings No. 009
Cyber Security

WME Security Briefing 08 May 2024

Exploitable vulnerability in Microsoft Internet Explorer, used to deploy VBA Malware Overview Cybersecurity researchers discovered a severe exploitation targeting a bug that had already been patched in the Microsoft Internet Explorer browser. Their report added that

Read More »
WME Cybersecurity Briefings No. 008
Cyber Security

WME Security Briefing 03 May 2024

Security Bulletin: MITRE Corporation Targeted by Nation-State Cyber Attack Overview The MITRE Corporation, a prominent security and cybersecurity researcher in the USA, has fallen prey to compromise in its environment because of a sophisticated cyberattack from

Read More »
Be assured of everything

Get WME Services

Stay ahead of the competition with our Professional IT offerings.