amendala
asked on
Why is System Center Endpoint Protection 2012 SP1 inconsistent in applying antimalware policies?
Folks -
I've recently created a new Client Settings Profile and Antimalware Policy within SCCM 2012 SP1. I've created a collection with test machines (including some XP clients and some Windows 7 clients). I deployed the Client Settings and Antimalware Policy to that collection. My old antivirus software (Forefront Client Security) was removed and SCEP 2012 SP1 was layed down in its place.
The installation went fine on all my test machines, however, I'm noticing significant inconsistencies in the application of the antimalware policy.
Here are some bullet points of inconsistency:
- SCEP on Windows 7 machines do not receive the file extension or file path exclusion lists.
- The "Disable the client user interface" setting does not dynamically apply. Only the setting that existed upon the client's first install takes effect. If you change this later in the antimalware policy, the client UI will not reappear/disappear.
- If real-time protection is turned off by an administrator on the client (by unchecking it and providing a credential through the UAC prompt), it will never get reenabled even though it is required by the Antimalware Policy.
Has anyone else seen this? Am I looking at an extremely buggy client? Or am I missing something? There's more to the list but these are some examples I found within only 30 minutes of testing.
The latest April 2013 update for the client (KB 2831316) has been distributed via our WSUS infrastructure and makes no difference to these items.
I've recently created a new Client Settings Profile and Antimalware Policy within SCCM 2012 SP1. I've created a collection with test machines (including some XP clients and some Windows 7 clients). I deployed the Client Settings and Antimalware Policy to that collection. My old antivirus software (Forefront Client Security) was removed and SCEP 2012 SP1 was layed down in its place.
The installation went fine on all my test machines, however, I'm noticing significant inconsistencies in the application of the antimalware policy.
Here are some bullet points of inconsistency:
- SCEP on Windows 7 machines do not receive the file extension or file path exclusion lists.
- The "Disable the client user interface" setting does not dynamically apply. Only the setting that existed upon the client's first install takes effect. If you change this later in the antimalware policy, the client UI will not reappear/disappear.
- If real-time protection is turned off by an administrator on the client (by unchecking it and providing a credential through the UAC prompt), it will never get reenabled even though it is required by the Antimalware Policy.
Has anyone else seen this? Am I looking at an extremely buggy client? Or am I missing something? There's more to the list but these are some examples I found within only 30 minutes of testing.
The latest April 2013 update for the client (KB 2831316) has been distributed via our WSUS infrastructure and makes no difference to these items.
ASKER
Unfortunately, that isn't my experience. The SCEP clients I've deployed have been active for over a week.
I know policy is updating as some features work, but the fact that some work and some don't bothers me. I'm very close to opening a Premiere case with Microsoft.
It just doesn't make sense that some policy attributes work, some don't, and of all things, some don't work on Windows 7 but they work on XP. Wow. :)
I know policy is updating as some features work, but the fact that some work and some don't bothers me. I'm very close to opening a Premiere case with Microsoft.
It just doesn't make sense that some policy attributes work, some don't, and of all things, some don't work on Windows 7 but they work on XP. Wow. :)
That is very odd needless to day. I wish I had an answer for you in this case but the only thing I can think of is conflicting policies but they are labeled by priority so that cannot be the case.
If you find a solution please post back on here because I am very curious on why and how this occurred.
If you find a solution please post back on here because I am very curious on why and how this occurred.
ASKER
I'll post back when I know something. These machines had FCS on them before which obtains its settings via GPO. I'm wondering if tatoo'd GPO settings from the prior AV client, which obviously carries the same executable name (msmpeng.exe), implying significant similarity, are part of the problem.
I denied application of the FCS GPO to my workstation and allowed numerous SCCM policy refresh cycles to pass with no difference in behavior.
I denied application of the FCS GPO to my workstation and allowed numerous SCCM policy refresh cycles to pass with no difference in behavior.
I've requested that this question be deleted for the following reason:
Not enough information to confirm an answer.
Not enough information to confirm an answer.
ASKER
I have determined the cause of this problem.
SCEP relies on Local Group Policy Processing in order to apply its policy settings. In organizations that have deployed a domain-global GPO to disable Local Group Policy Processing, such as my own, SCEP policy settings cannot be properly compiled and applied.
Upon removing this global GPO setting from all computers in my domain, SCEP began accurately and consistently applying policy.
SCEP relies on Local Group Policy Processing in order to apply its policy settings. In organizations that have deployed a domain-global GPO to disable Local Group Policy Processing, such as my own, SCEP policy settings cannot be properly compiled and applied.
Upon removing this global GPO setting from all computers in my domain, SCEP began accurately and consistently applying policy.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I determined the problem and fixed it.
If you think about it that would be normal as you make the changes on the Server for the said policy it will take a while for all the clients to report to the SCCM for any changes in policies.