SCEP Policy Update Troubleshooting

Because I'm a glutton for punishment, I recently started rolling out System Center Configuration Manager 2012 R2 SP1 and System Center Endpoint Protection across our VDI environment. There are always some considerations to be made in a pooled desktop / gold image type environment when loading software that uniquely identifies devices, but lucky for me SCCM/SCEP handled this just fine without any tweaking. However, there were some nuances to how SCEP policies are applied that caused some serious hair-pulling before I spotted the issues.

Antimalware Policy Basics

I should clarify I few points to ensure your policies even stand a chance of being applied in the first place:

• Default policies will apply if you have not created any custom policies.
• Custom policies are created under Assets and Compliance > Endpoint Protection > Antimalware Policies.
• Custom policy settings will always override default policies (unless you have one of the issues described in the next sections).
• Policies must be applied to a collection containing the device(s) you want to apply it to before they do anything.
• In SCCM 2012 R2 SP1, policies are now cumulative and will do an automatic "client side merge" by default, obeying the order of precedence you specify in the Antimalware Policies section. This also means if two different policies apply to a workstation based on collection membership and each policy has unique exclusions, all exclusions will be added to the client. In previous versions of SCCM, this was not the case (only one policy was applied to each client and a manual server-side merge was required to combine multiple policies).
• Refresh machine/computer policy from the client to force it to process new policy changes. For faster policy adjustments,  Adjust the Client policy polling interval in the applied Client Settings to increase the refresh interval.

So let's assume you have some custom policies, applied to a collection, and machines in that collection aren't getting the policy:

Verify Policy is Actually Applied

The first thing to do is check and make sure your device has actually decided to acquire the policy. The easiest way to do this is to open SCEP on the device and check Help > About. You should see all the custom and default policies here:

If you aren't seeing policies here, then there is a problem between SCEP and SCCM. Your client is unaware, either due to an error or misconfiguration, that it should even try to apply any policies. 

• In SCCM, select the device from the Assets and Compliance screen and move to the Antimalware Policies tab. Check the Policy Application State - it should show your policies there and they should show "Succeeded" with a recent update date/time. 
• If the policy isn't there, then you probably didn't deploy it correctly in SCCM. 
• If the policy appears, but doesn't show anything for the application state, then the client hasn't yet received it. Force the device to update machine policy  and wait a few minutes.
• Check the CcmExec.log and EndpointProtectionAgent.log files under c:\windows\CCM\Logs for errors.

Assuming that all looks good ...

Verify Policies Are Applied in the Right Order

If you some of your custom policies are applying, but not the ones you expect, check and ensure that they are applying in the correct order. You can check which policies are being obeyed by querying the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM\EPAgent\LastAppliedPolicy.

Policies listed there with higher values take precedence over settings with lower values, as I understand it. "Exclusion" policies will have the same value usually, indicating they will be merged together. 

If that still doesn't help ...

Verify Local GPOs Can Be Applied

If you find that the policies are appearing the SCEP client correctly under "About", but you aren't actually getting the exclusions and settings you expect, the issue might be with local GPO processing. SCCM applies policies by using the client to inject registry settings via the local GPO, which SCEP then reads. If those policies are received by SCCM, but never make it in to the registry, then you'll get this behavior.

Run RSoP and check under Computer Configuration\Administrative Templates\Extra Registry Settings - You should see all of your SCEP policy settings here.

If they don't show up (or you don't have the "Extra Registry Settings" area), check the RSoP report for a setting called  Turn off Local Group Policy objects processing under Computer Configuration/Administrative Templates/System/Group Policy. If it is applied, RSoP will tell you you which GPO is enforcing it. Change it to Disabled/Not Configured, because this setting will effectively prevent the local GPO that SCCM has injected with your SCEP settings from actually applying:

Setting Path:

Computer Configuration/Administrative Templates/System/Group Policy

Setting: Turn off Local Group Policy objects processing

And finally, if you still get inconsistent policy application ...

Verify GPO Registry Settings Can Be Refreshed After Startup

There is another GPO setting that can trip you up, and that is the Registry Policy Processing option called Do not apply during periodic background processing. This prevents registry changes requested via GPO updates from being applied during the periodic background processing of GPOs, effectively only allowing them to be applied when the computer configuration policy is applied during boot. Having this option on will stop SCEP from receiving updated registry settings from the local GPO after it boots. If you find that you are required to reboot to get policy updates, just check RSoP for this setting and if you find it, remove it:

Setting Path:

Computer Configuration/Administrative Templates/System/Group Policy 

Setting: Registry Policy Processing 

Option: Do not apply during periodic background processing

 Hopefully these tips will save you some of the headache of getting SCEP policies reliably deployed!