System Center Endpoint Protection – Updated ADMX Template for the March 2016 Update – KB3106514

The new update has been out for a little while now (KB3106514) and brings with it three new settings.

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Microsoft Antimalware\MpEngine
DWORD name: MpEnablePUS

This setting enables detection and removal of Potentially Unwanted Applications (PUA) downloaded through IE, Firefox or Chrome. One thing about this is that it will only apply to new detections going forward. This setting will not cause existing PUAs to be detected and removed.

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Microsoft Antimalware\UX Configuration

DWORD name: SuppressRebootNotification

This is a setting to suppress the reboot notification from the client if it detects that a reboot is required to finish the clean-up of any malware. This is useful in shared environments (RDS, etc.), where a this kind of thing would not be fun.

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Microsoft Antimalware

DWORD name: ThreatFileHashLogging

This setting records an event with ID 1120 to the log file containing the SHA-1 hash of the affected file for more research and correlation with other infections or threats.

There’s also a link from the knowledge base page to a script on the PowerShell gallery for setting up anti-malware client updates on a UNC share, which is quite nice for new deployments, without using something like System Center Configuration Manager (SCCM) or Windows Server Update Services (WSUS).

I have added these updates to my ADMX template for System Center Endpoint Protection, which can be downloaded from GitHub. Note that from this update on, the file names and data drop the 2012R2 version number from the file name, which makes more sense going forward. The old files are still there for reference.

The direct links to the files are:


It’s been just over a year since the last policy template settings change from Microsoft for their Endpoint Protection products and still no sign of an official file! I’ll keep on with the updates for this until Microsoft sort it out.


I’ve made a couple more changes to add two new policy options that I had previously overlooked, these are:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Microsoft Antimalware\Real-Time Protection

DWORD name: DisableScriptScanning

This setting provides an admin override to disable script scanning.

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Microsoft Antimalware\Real-Time Protection

DWORD name: LocalSettingOverrideDisableScriptScanning

This setting allows the local client setting for script scanning to take precedence over a group policy setting.

4 thoughts on “System Center Endpoint Protection – Updated ADMX Template for the March 2016 Update – KB3106514”

  1. Dave, thanks for putting this together. I have some feedback for you. First, in the ADML file, line 131, 293, and 547 had invalid quotation mark characters. I had to backspace them and retype them. Once I did that, the ADMX/ADML worked great!

    Second, I have a couple of registry keys set in my older policies that I think are not defined in the ADMX:
    Key: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Microsoft Antimalware\Real-Time Protection
    Value: LocalSettingOverrideDisableScriptScanning
    Type: DWORD

    Key: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Microsoft Antimalware\Real-Time Protection
    Value: DisableScriptScanning
    Type: DWORD

  2. Hi Frank, Thank you for the feedback, it’s much appreciated!

    I’ve sorted those quotes, it must have slipped in ages ago when i copied across various explanations for the ADML from another source. I’ll also add those policy options in the next day or so, the work is getting the explanations in the ADML file to make sense :)

    It looks like it’s a couple more of the settings added since the official FEP 2010 template that I’ve managed to miss, so at some point I’ll do a proper review of what is there and what i’m missing.

  3. We implemented MpEnablePUS = 1 a while back (with configuration baselines) on some of our computers. But even when we tried to trip this on test machines with several known PUAs, it did not detect. Has anyone seen this work, and do the detection instances appear in SCEP reporting prefixed as PUA/ or PUS/ ?


    1. Hi Henry, apologies for the late comment. I haven’t seen PUA detect anything in the wild myself yet, however they appear to be detected as PUA:Win32/malwarename.

Your words