Allowing users to configure real-time protection settings on SCEP client

If users are allowed to configure real-time protection settings can a user disable it? If a user can disable it, will it re-enable after a certain amount of time has passed?

Thanks

March 20th, 2015 11:50am

Hi I AM Sir Ask Alot,

If you allow the users to configure real-time settings, then no once disabled it will stay disabled until you either change the policy or the user enabled it themselves.

Free Windows Admin Tool Kit Click here and download it now
March 20th, 2015 12:06pm

Instead of configuring the "allow users on client computers to configure real-time protection settings" in SCEP policy, you could try setting the corresponding registry keys directly via compliance settings. The settings are in

HKLM\SOFTWARE\Policies\Microsoft\Microsoft Antimalware\Real-Time Protection

LocalSettingOverrideDisableBehaviorMonitoring

LocalSettingOverrideDisableIntrusionPreventionSystem

LocalSettingOverrideDisableOAVProtection

LocalSettingOverrideDisableOnAccessProtection

LocalSettingOverrideDisableRealTimeMonitoring

LocalSettingOverrideDisableScriptScanning

LocalSettingOverrideDisableRealTimeScanDirection

(all are REG_DWORD type)

Set LocalSettingOverrideDisableRealTimeMonitoring to 0 and the rest to 1. The result is that the parent setting for "Turn on real-time protection" is enabled and grayed out in the GUI, but the child settings can still be configured individually.


March 20th, 2015 12:21pm

Hi Kevin, have you tested that process?  Just curious if those registry will get overwritten during the next SCEP policy evaluation?  I haven't ever directly edited those keys but I know if many cases, editing SCCM registry directly just gets overwritten to the correct settings defined in policy.

Thanks!

 
Free Windows Admin Tool Kit Click here and download it now
March 20th, 2015 12:48pm

Great, thanks guys.

I appreciate it 

March 20th, 2015 1:05pm

When I refresh policy, it does not seem to change the value of LocalSettingOverrideDisableRealTimeMonitoring back to 1. Other than that, I have not done any testing. In my original comment, I said "instead of configuring vis SCEP policy" but what I should have said was "in addition to configuring the policy", since the policy has to be configured one way or the other. So set it to yes to allow users to configure, then use another method like compliance settings to change just the value of LocalSettingOverrideDisableRealTimeMonitoring to 0.
Free Windows Admin Tool Kit Click here and download it now
March 20th, 2015 1:21pm

Actually, I take that back. The setting did revert, it just took longer than I expected. So I guess that means this won't work long-term unless you are running standalone SCEP and not using ConfigMgr to push policy. It's at least possible if one wanted/needed to go that route.
March 20th, 2015 1:30pm

Hi I AM Sir Ask Alot,

If you allow the users to configure real-time settings, then no once disabled it will stay disabled until you either change the policy or the user enabled it themselves.

Free Windows Admin Tool Kit Click here and download it now
March 20th, 2015 4:01pm

Instead of configuring the "allow users on client computers to configure real-time protection settings" in SCEP policy, you could try setting the corresponding registry keys directly via compliance settings. The settings are in

HKLM\SOFTWARE\Policies\Microsoft\Microsoft Antimalware\Real-Time Protection

LocalSettingOverrideDisableBehaviorMonitoring

LocalSettingOverrideDisableIntrusionPreventionSystem

LocalSettingOverrideDisableOAVProtection

LocalSettingOverrideDisableOnAccessProtection

LocalSettingOverrideDisableRealTimeMonitoring

LocalSettingOverrideDisableScriptScanning

LocalSettingOverrideDisableRealTimeScanDirection

(all are REG_DWORD type)

Set LocalSettingOverrideDisableRealTimeMonitoring to 0 and the rest to 1. The result is that the parent setting for "Turn on real-time protection" is enabled and grayed out in the GUI, but the child settings can still be configured individually.


March 20th, 2015 4:17pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics