I though this recent article posted on the SCCM Team’s blog might be worth sharing. I decided to copy the article and modified it slightly with credit to the original author below.
Several customers have reported that the System Center 2012 Endpoint Protection (SCEP) client stops reporting any status to System Center 2012 Configuration Manager sites when the following update is installed on Windows 8.1 clients:
Clients will record errors that resemble the following in the ExternalEventAgent.log file.
And
To prevent this issue from continuing we have revised the detection logic for KB3025417; as of Friday June 12, 2015 it is no longer offered to clients that are also running System Center Endpoint Protection.
Uninstalling KB3025417 from affected computers, followed by reinstalling the SCEP client, resolves the reporting issue.
As an alternative to uninstalling the update, running the following command on the client will restore reporting functionality. This command will re-register SCEP client as the preferred AV client instead of the built-in Windows Defender client. After command execution, restart the computer for the provider change to take effect.
Register-CimProvider.exe -ProviderName ProtectionManagement -Namespace root\microsoft\ProtectionManagement -Path "C:\Program Files\Microsoft Security Client\ProtectionMgmt.dll" -Impersonation True -HostingModel LocalServiceHost -SupportWQL -ForceUpdate
This interoperability issue between Windows Defender and System Center Endpoint Protection will be resolved in future platform updates for Windows Defender.
Original Author: Brian Huneycutt, Software Engineer, Enterprise Client and Mobility
Article Reference: http://blogs.technet.com/b/configmgrteam/archive/2015/06/18/scep-client-reporting-issues-after-installing-kb3025417-on-win-8-1.aspx
Deploying Alternative Fix using SCCM
As a commenter points out in the original article, if you are planning to use the alternative method above and run a package using SCCM to execute the Register-CimProvider.exe command; note that running a package in SCCM will launch a 32bit process by default. That means the command above won’t work if your Windows 8.x systems are x64 builds. The command has to be run from a 64bit CLI process, so you either have to trick the 64bit file system redirection to fire-up CMD.exe or use the Application Model in SCCM. Comment Credit: Martin Bengtsson
My response to this; I would normally configure a program for 64-bit using a path that begins with ‘%windir%\SysNative\cmd.exe’ – as the commenter suggests, using the Application Model in SCCM has a option for flagging the process to natively run in 64-bit which might be more preferable.