This post is obsolete and this process will no longer function. Please see Creating an Endpoint Protection Alert using PowerShell (windowsmanagementexperts.com) 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.
Background
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 =
$infection.ConvertToDateTime($infection.EPAntispywareSignatureLastUpdateDateTime)}
If (($infection.EPLastFullScanDateTimeEnd) -gt “1”) {$fullscan =
$infection.ConvertToDateTime($infection.EPLastFullScanDateTimeEnd)}
If (($infection.EPLastInfectionTime) -gt “1”) {$lastinf =
$infection.ConvertToDateTime($infection.EPLastInfectionTime)}
}
$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 “192.168.2.3192.168.2.4”. 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.
