共用方式為

System Center Configuration Manager 2012 – SCEP Policy behavior

  • 發行項

Michael Michailidis, our PFE from Greece, shares a recent System Center Endpoint Protection scenario he worked on.

Recently I worked on a case regarding the policy behavior of System Center Endpoint Protection (SCEP) through Configuration Manager 2012 SP1. A customer of mine realized that all the custom policies, deployed in different collections, had the same generic name Antimalware Policy. Through this post I would like to try and reveal the truth around SCEP and its operational mechanism.

SCEP policies

Let’s start with the RTM version of Configuration Manager 2012. In that version if you deployed a SCEP client to a device collection it would be easy to check which policy has been applied. When you open the SCEP client UI on the client computer, you click the pointing arrow next to Help and select the option ‘About System Center Endpoint Protection’ . In the About window we have a “bunch” of information. At the bottom you will see Policy Name. In that section we can check the applied policy (the default or custom).

Client Side Merge in SP1

After the release of Service Pack 1 for Configuration Manager we notice many changes. Firstly, in the screenshot below you can see a SCEP client UI after Service Pack 1:

SCEP UI after SP1

The other major change has to do with the way SCEP client processes anti malware policy. This new functionality is called Client Side Merge.

“ Multiple antimalware policies that are deployed to the same client computer are merged on the client. When two settings are in conflict, the highest priority option is used. Some settings are also merged, such as exclusion lists from separate antimalware policies. Client-side merge also honors the priority that you configured for each antimalware policy.”

Read more about the changes here. This means that if more than one antimalware policy is targeted on a collection, then those policies will be merged together and the highest priority will win. The “winner” options will be applied at the client. On the one side this is good, in case you have many policies and many clients on different device collection but on the other side we understand that this will be an overhead to troubleshoot. For this reason, we need a way to determine which policy is applied. Below you may read on a few options regarding how we can identify the applied policy.

Identifying the applied policy

Option 1: Checking the registry key

The first option involves the registry. You need to check the following key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM\EPAgent\LastAppliedPolicy and see which policies are merged. In our example below you will notice 2 Antimalware Policies:

  • Default Antimalware Policy
  • MMLab_EP_Configuration Manager 2012 (custom)
Antimalware policy listing in registry

    

Option 2: Query Registry to list the merged policies

The second option involves again the registry but this time we will make a query to list all merged policies. You need to open an administrative command prompt and type this command:

reg query HKLM\SOFTWARE\Microsoft\CCM\EPAgent\LastAppliedPolicy /f 2 /d

Querying the registry

In the output list we see the main “settings” that we find within Antimalware Policies. These are:

  • Advance setting
  • Excluded
  • Realtime Config
  • Scan Schedule
  • Scan
  • Signature Update
  • Spynet
  • Threat Default Action

If these settings are merged the value in the registry will be 0×00000002 (2). In our example the MMLab policy has the highest priority and these settings are applied.

Option 3: Review Antimalware policies from Configuration Manager Console

The third option involves the Configuration manager console. You can navigate in the Assets and Compliance workspace, choose Devices and locate the computer that you want to examine, select it and then click on the Antimalware Policies tab as shown below.

Antimalware policies from Config Manager Console

You will see a list of antimalware Policies (and their associated priority) listed.

Configuration Manager 2012 R2

In the new version it seems that we have a small change in the behavior of SCEP policy and in what is visible in the About window of the client. As you can see in the following screenshot now we are able to see all the applied/merged Antimalware Policies that target our client machine‘

SCEP 2012 R2 About screen

Now that you have a starting point to troubleshoot the Antimalware policy for SCEP, feel free to post your comments and questions on this blog. We hope it was really useful for you!

Original content from Michael Michailidis; posted by MSPFE editor Arvind Shyamsundar.

Comments

  • Anonymous
    January 01, 2003
    Hi, great blog!

    How do I force the policies though, or apply them urgently?
  • Anonymous
    January 01, 2003
    Just the standard Machine Policy Retrieval & Evaluation Cycle from the SCCM client...to easy! :)
  • Anonymous
    August 28, 2014
    I have several custom policies applied to my collections, but the policies never make it to the client and in the console when I select the client and select the Antimalware Policies tab, the Policies are displayed but the Policies never show up as Succeeded. I have tried reinstalling the client and re-creating the policies, but no policies other than the Default Client Antimalware Policy ever show up as succeeded or show up on the client. Any suggestions?

    Thanks,
    Jon
  • Anonymous
    October 04, 2014
    Any thoughts on how to generate a report of SCEP policies and their effective results on a client machine?
  • Anonymous
    May 19, 2016
    The problem I had was on the SCCM server with the task scheduler located below. Under Conditions the selection of "Start the task only if computer is idle for" was set to "1 Minute". Taking a look at that task scheduled history it threw an error saying "Could not start task ... because machine was not idle.Microsoft -> Microsoft Antimalware -> Microsoft Antimalware Scheduled Scan
  • Anonymous
    October 18, 2016
    The comment has been removed