The latest version of System Center Endpoint protection (4.9.218.0 – March 8, 2016) has a bug in the included PowerShell Module MpProvider.psd1 located in the default directory of C:\Program Files\Microsoft Security Client\MpProvider.
The latest version of System Center Endpoint protection (4.9.218.0 – March 8, 2016) has a bug in the included PowerShell Module MpProvider.psd1 located in the default directory of C:\Program Files\Microsoft Security Client\MpProvider.
The bug is currently a reference to a nested module that doesn’t exist, if you attempt to import this module, you’ll see the following.
The reason this is so important, is that the Antimalware Intelligence Pack that comes down from the “Malware Assessment” solution in Operational Insights, requires access to this module in order to gather status information regarding signature dates, definitions, malware activity, etc.
You can view the code that’s run on any Operational Insight agents (or SCOM connected agents) that have the Antimalware Assessment solution configured here.
How this script works is by attempting to import the required module “MpProvider.psd1” to gather information regarding the status of SCEP. If the import was successful, the script will continue to run gathering information about SCEP. However, if the module fails to import, the script will fall back to gathering information about the “Malicious Software & Removal Tool”.
You can see this in the Operations Manager event viewer (Event ID’s 9991-9993). These events will show the information that’s gathered by the Malware Status collection scripts, which is also the actual information that’s transmitted up to Operational Insights.
The quickest fix for this bug is to simply modify the MpProvider.psd1 module and remove the portion highlighted in the top screenshot of this article ‘MSFT_MpWDOScan.cdxml’. The reference to this cdXML does not existing in the “C:\Program Files\Microsoft Security Client\MpProvider” folder on any client I’ve checked. You could push this updated module file out to affected clients using Group Policy Preferences, or simply wait for a fix from Microsoft (no ETA). Or, better yet Microsoft provided me with the missing module that you could deploy to the directory in question (attached at the bottom), both fixes will work.
If we modify the module, then wait for the collection cycle to re-run (default hourly), you’ll NOW see in the Event Log that proper SCEP information is gathered.
This information will flow up to Operational Insights and can be seen by querying for “ProtectionStatusRank = 150”.
It may take some time depending on your data retention for the old “Not Protected” client information to age out and be removed from Operational Insights before everything reports correctly.
Also, note that “Behavior Monitoring” in SCEP MUST be Enabled in your SCEP policies for Operational Insights to properly report healthy, protected SCEP clients.
Written By:
Softlanding
More By This Author
