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

  • Question

  • 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

    Friday, March 20, 2015 3:46 PM

Answers

  • 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.

    Friday, March 20, 2015 4:01 PM
  • 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.


    Friday, March 20, 2015 4:17 PM

All replies

  • 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.

    Friday, March 20, 2015 4:01 PM
  • 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.


    Friday, March 20, 2015 4:17 PM
  • 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!

     
    Friday, March 20, 2015 4:44 PM
  • Great, thanks guys.

    I appreciate it 

    Friday, March 20, 2015 5:00 PM
  • 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.
    Friday, March 20, 2015 5:16 PM
  • 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.
    Friday, March 20, 2015 5:25 PM