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.
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 ?
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
- Create an SQL server policy. This would contain exclusions from https://support.microsoft.com/en-us/help/309422/choosing-antivirus-software-for-computers-that-run-sql-server
- Create an SCCM server policy. https://blogs.technet.microsoft.com/systemcenterpfe/2017/05/24/configuration-manager-current-branch-antivirus-update/
- Create a payroll server policy – specific to the software…. look for the major processes that it runs and add them as exclusions.
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.