SCCM antimalware client policies – do they merge ?

There seems to be a great deal of mis-information about this floating around the web…. despite articles like this that lay it out quite well.

When you create an SCCM antimalware policy, the settings do merge.

You do not have to create bucketloads of policies and apply/re-apply the same settings over and over and over again.

This insane practice makes anti-malware policies much harder to manage and track.

 

Testing

In order to prove this for yourself, do the following:

  • add a process into the default anti-malware policy – give it an obvious name such as “DefaultPolicyExclusion.exe”
  • Now create a new policy, add an exclusion called “NewPolicyexclusion.exe”
  • Apply the new policy to a machine and update policy on that machine
  • Check the exclusion list (settings | Updates and Security | windows security | Virus and threat protection | manage settings | Add or remove exclusions)
  • You can now see that both exclusions are listed

 

You can also run the following from a command prompt to see which policies are applied

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

Notice that the exclusions are applied from both “Default client antimalware policy” and whatever you called your new policy.

 

Why this matters

We have clients that (correctly) create new antimalware policies for different types of servers…. e.g. to exclude sqlservr.exe on SQL servers – which makes complete sense.

Unfortunately, they then proceed to define every other setting that is available….. which means that if we want to change real time settings (for example) – we need to go into every single policy to do so. A little painful but not to base with 10 policies, but just unnecessarily time consuming when there are hundreds.

 

What about conflicting settings ?

This is where priority comes into play.

Its very simple… in the even of a conflicting setting (e.g. Real time scanning enabled in one policy and disabled in another) then the one with the lowest priority will win. This is referred to as “Order” in some parts of the console and Priority in other parts of the console. (As of SCCM 1910)

Notice that the default policy has a priority of 10000, which is not changeable – and therefore will always be the lowest priority settings.

 

A better way

Just like your SCCM client policies, the best way to handle anti-malware policies is to set the defaults and then only make additional policies where you need to deviate from those defaults.

Set all the default settings for all machines across the fleet in the “Default Client antimalware Policy”, then create additional policies where required…. but only set the specific settings that deviate from the default settings – not every setting!

 

Another approach, for slightly larger organisations is to:

  • Leave the default policy alone
  • Create a Default workstation policy – which the desktop guys control
  • Create a Default server policy – which the server guys control
  • And so on (for different area’s of the business if there is a management demarcation)
  • Deploy appropriately

The downside of this model is that the default policy will keep needing to moved to the lowest priority each time you create a new policy.

 

What should i be excluding ?

https://social.technet.microsoft.com/wiki/contents/articles/953.microsoft-anti-virus-exclusion-list.aspx

 

A practical example

In this example were going to focus on an organisation with x00 servers, 2 of which are:

  • SCCM with SQL co-loctaed
  • Payroll application server with SQL co-located

 

In this case we would

 

Apply the SQL server policy to anything running SQL

Apply the SCCM server policy to anything running SCCM

Apply the payroll server policy to the payroll server

 

This way, when we update the SQL server policy – it flows through to all SQL servers automatically. We dont have to update the SCCM policy and the payroll server policy.

Leave a Reply