top of page

Failure Deploying Applications with SCCM\MECM with Error 0x87d01106 and 0x80070005

Updated: Jul 1, 2023

I encountered an issue with SCCM\MECM failing to deploy the LAPS application to clients and servers. This was previously working fine but now was failing with a Past Due error in Software Center.

The AppEnforce.log produced the only meaningful SCCM error events of 0x87d01106 and 0x80070005.


CMsiHandler::EnforceApp failed (0x80070005).

AppProvider::EnforceApp - Failed to invoke EnforceApp on Application handler(0x80070005).

CommenceEnforcement failed with error 0x80070005.

Method CommenceEnforcement failed with error code 80070005

++++++ Failed to enforce app. Error 0x80070005. ++++++

CMTrace Error Lookup reported ‘Access denied’


Invalid executable file C:\Windows\msiexec.exe

CMsiHandler::EnforceApp failed (0x87d01106).

AppProvider::EnforceApp - Failed to invoke EnforceApp on Application handler(0x87d01106).

CommenceEnforcement failed with error 0x87d01106.

Method CommenceEnforcement failed with error code 87D01106

++++++ Failed to enforce app. Error 0x87d01106. ++++++

CMTrace Error Lookup reported

Failed to verify the executable file is valid or to construct the associated command line.

Source: Microsoft Endpoint Configuration Manager

Interestingly testing revealed that .msi applications, configuration items aka compliance and WDAC policy were affected with .exe deployments remaining unaffected. Executing the install string from the administrator account also worked. Somewhat concerning as SCCM deployments execute as System, the highest privilege possible, yet all application installs failed across the entire domain.

At this point, Google is normally your friend..... but the results suggested PowerShell, and the wrong user context, as it's a msi issue, these suggestions were not helpful. Clearly, I'm asking the wrong question......

When in doubt or.... stuck, trawl the eventlogs, the SCCM logs weren't going to give up anything further.

Fortunately, in fairly short order the following errors were located in the Windows Defender log.

Microsoft Defender Exploit Guard has blocked an operation that is not allowed by your IT administrator.

For more information please contact your IT administrator.

ID: D1E49AAC-8F56-4280-B9BA-993A6D77406C

Detection time: 2023-02-23T21:03:46.265Z


Path: C:\Windows\System32\msiexec.exe

Process Name: C:\Windows\System32\wbem\WmiPrvSE.exe

Target Commandline: "C:\Windows\system32\msiexec.exe" /i "LAPS.x64.msi" /q /qn

Parent Commandline: C:\Windows\system32\wbem\wmiprvse.exe -Embedding

Involved File:

Inheritance Flags: 0x00000000

Security intelligence Version: 1.383.518.0

Engine Version: 1.1.20000.2

Product Version: 4.18.2301.6

Now I know the correct question to ask Google 'D1E49AAC-8F56-4280-B9BA-993A6D77406C', with Attack Surface Reduction (ASR) being the culprit. The following is an extract from the Microsoft page:

'Block process creations originating from PSExec and WMI commands


Block process creations originating from PSExec and WMI commands

This rule blocks processes created through PsExec and WMI from running. Both PsExec and WMI can remotely execute code. There's a risk of malware abusing the functionality of PsExec and WMI for command and control purposes, or to spread infection throughout an organization's network.

Warning Only use this rule if you're managing your devices with Intune or another MDM solution. This rule is incompatible with management through Microsoft Endpoint Configuration Manager because this rule blocks WMI commands the Configuration Manager client uses to function correctly.

There is no fix, only a workaround, involving updating the ASR setting Block Mode to Audit Mode in Group Policy.

Open GPO Management and locate the ASR rules under Windows Components/Microsoft Defender Antivirus/Microsoft Defender Exploit Guard/Attack Surface Reduction.

Open the 'Configure Attack Surface Reduction Rules'.

Update value name 'D1E49AAC-8F56-4280-B9BA-993A6D77406C' from 1 to 2.

Gpupdate /force to refresh the GPO's on the client, then check the eventlog for 5007 recording the change from Block to Audit Mode.

Test an SCCM Application deployment to confirm the fix.

One final check of the event log confirming event id 1122 for the deployed application.

126 views0 comments

Recent Posts

See All


Rated 0 out of 5 stars.
No ratings yet

Add a rating
bottom of page