SCCM Error Codes: What the Common Ones Mean and How to Fix Them

Part of our SCCM and ConfigMgr guides: every related guide in one place.

Any SCCM (Configuration Manager) error code can be decoded in seconds: open CMTrace, choose Tools, then Error Lookup, and paste the hex value (for example 0x87D00324) or its signed decimal form (-2016410844). The description tells you which component failed, and the matching client log tells you why.

This reference covers the codes that turn up most often in Software Center, the console’s deployment status view and the client logs, grouped by area. Each one lists what it means, the usual causes, the log to open first and the fix that normally works. For wider ConfigMgr material, the SCCM and ConfigMgr guides hub collects everything else on the site.

How to look up any ConfigMgr error code

ConfigMgr reports the same error in two formats depending on where you look. Software Center and most logs show the hex value, while the console’s deployment status and some reports show a signed (negative) decimal. They are the same 32-bit number, so you need to be able to convert between them.

1. Open CMTrace. Since ConfigMgr 1806 it is installed with every client, so it is already on the machine you are troubleshooting. See CMTrace bundled with the Configuration Manager client install for the background.
2. Press Ctrl+L (or Tools, then Error Lookup) and paste the code. CMTrace accepts hex with the 0x prefix or the decimal value, and it checks Windows, WMI and ConfigMgr message tables.
3. Convert decimal to hex if the console gives you a negative number. PowerShell does it in one line.

C:\Windows\CCM\CMTrace.exe
<ConfigMgr install dir>\tools\CMTrace.exe

# Decimal to hex
'0x{0:X8}' -f -2016410844        # returns 0x87D00324

# Hex to signed decimal
[int]0x87D00324                  # returns -2016410844

A quick rule of thumb helps you decide where to look. Codes starting 0x87D are raised by the ConfigMgr client itself. Codes starting 0x8007 are plain Win32 errors wrapped as HRESULTs, so the last four hex digits are the Win32 error number (0x80070005 is Win32 error 5, access denied). Codes starting 0x8024 come from the Windows Update Agent, and 0x80072EE codes come from WinINet (network). For the Windows Update family, Windows Update error codes explained goes into more depth.

All client logs referenced below live in the same folder unless stated otherwise:

C:\Windows\CCM\Logs\

Application and software deployment errors

0x87D00324 : the application was not detected after installation completed

Decimal -2016410844. This is the most common application deployment error and it almost never means the installer failed. The install command ran and returned a success exit code, but the deployment type’s detection method then evaluated as “not installed”, so ConfigMgr marks the deployment as failed.

Common causes: a detection rule pointing at the wrong version number, a 32-bit versus 64-bit registry or Program Files path mismatch, an MSI product code that changes between builds, or an installer that hands off to a child process and exits before the real install finishes.

Logs to check:

C:\Windows\CCM\Logs\AppEnforce.log     (exit code and "not detected" line)
C:\Windows\CCM\Logs\AppDiscovery.log   (what the detection method actually checked)

• Install the application manually on a test machine, then check the exact file version, registry value or product code that exists afterwards.
• For file or registry detection on 64-bit Windows, tick or untick “This file or folder is associated with a 32-bit application on 64-bit systems” to match the real location.
• If the installer spawns a second process, wrap it in a script that waits for completion (for example Start-Process -Wait).

0x87D00607 : content not found

Decimal -2016410105. The client asked the management point for content locations and got no usable distribution point back, so it cannot download the package. Software Center usually shows the deployment stuck on “Downloading” before it fails.

Common causes: content never distributed (or distribution failed) to a DP in the client’s boundary group, the client’s IP or AD site not covered by any boundary, or no fallback configured for the boundary group.

C:\Windows\CCM\Logs\LocationServices.log
C:\Windows\CCM\Logs\CAS.log
C:\Windows\CCM\Logs\ContentTransferManager.log
C:\Windows\CCM\Logs\DataTransferService.log

• In the console, check the content status of the application and redistribute to any DP showing a failure.
• Confirm the client’s subnet or AD site sits inside a boundary that belongs to a boundary group with that DP assigned for content.
• In CAS.log look for “Location request failed” or zero locations returned, which confirms a boundary problem rather than a download problem.

If content locations are returned but the download never moves, that is a different fault; see SCCM clients stuck on 0% downloading.

0x87D00213 : timeout occurred

Decimal -2016411117. The installation ran longer than the deployment type’s “Maximum allowed run time” (120 minutes by default for applications), so the client stopped waiting and reported failure. The installer process may still be running in the background.

C:\Windows\CCM\Logs\AppEnforce.log
C:\Windows\CCM\Logs\AppDiscovery.log

• Make sure the install command is genuinely silent. An installer waiting on a hidden prompt is the usual culprit, particularly when it runs as SYSTEM with no visible desktop.
• For large installs, raise “Maximum allowed run time” on the deployment type’s User Experience tab and keep the estimated time sensible.
• For software updates the same code means an update exceeded its maximum run time; adjust it on the update’s properties or with Set-CMSoftwareUpdate -MaximumExecutionMins.

0x80070002 : the system cannot find the file specified

Decimal -2147024894. Win32 error 2. In an application deployment it normally means the install command references a file that is not in the content, or a relative path that does not resolve from the client’s cache folder.

C:\Windows\CCM\Logs\AppEnforce.log
C:\Windows\ccmcache\<folder>\    (check what actually downloaded)

• Compare the file name in the install command with the files in the content source, including spelling and extension.
• Quote any path containing spaces, and reference scripts relative to the content folder rather than a mapped drive.
• If you changed the source files, update the content on the distribution points so clients get the new version.

0x87D1041C : application not detected after installation (co-managed devices)

Decimal -2016345060. This one catches people out in co-managed estates because it looks like a ConfigMgr code but is reported by the Intune Management Extension for Win32 apps. The meaning is the same as 0x87D00324: the installer finished, but the detection rule did not find the app. If you see it, the app came from Intune, not from a ConfigMgr deployment.

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log

Fix it the same way: confirm the real version, path or product code after a manual install and correct the Intune detection rule, paying attention to the 32-bit versus 64-bit registry setting.

Client installation errors

0x80070005 : access is denied

Decimal -2147024891. Win32 error 5. During client push it means the site server could not connect to the target’s ADMIN$ share or create the ccmsetup service, which points at the client push account’s permissions or the target’s firewall.

Site server: <ConfigMgr install dir>\Logs\ccm.log
Client:      C:\Windows\ccmsetup\Logs\ccmsetup.log

• Make sure the client push installation account is a local administrator on the target (usually via a GPO restricted group).
• Allow File and Printer Sharing and Windows Management Instrumentation through Windows Defender Firewall on clients.
• Test from the site server with dir \\<client>\admin$ using the push account. If that fails, ConfigMgr will fail too.

On an existing client, the same code in other logs usually means a file or registry key is locked or permissions have been tightened by security software or hardening policy.

0x80004005 : unspecified error

Decimal -2147467259. E_FAIL, the generic “something went wrong” error. On its own it tells you nothing; the meaningful information is always in the lines just above it in the log.

C:\Windows\ccmsetup\Logs\ccmsetup.log
C:\Windows\ccmsetup\Logs\client.msi.log

• In ccmsetup.log, scroll up from the failure and note the last component it was working on (prerequisite download, MP lookup, certificate check or MSI install).
• In client.msi.log, search for return value 3; the lines above it show the real failing action.
• A broken WMI repository or a half-removed old client is a frequent root cause. Removing the old client cleanly and reinstalling usually clears it; repairing unhealthy clients with CCMClean covers that process.

0x80070643 : fatal error during installation

Decimal -2147023293. This is MSI error 1603 wrapped as an HRESULT, returned when client.msi fails. It is another “look further up” code: the real cause sits in the MSI log.

C:\Windows\ccmsetup\Logs\client.msi.log

# Clean up and reinstall
C:\Windows\ccmsetup\ccmsetup.exe /uninstall
ccmsetup.exe /mp:<MP FQDN> SMSSITECODE=<site code>

Typical causes are a pending reboot, antivirus locking files, a corrupt WMI repository or leftovers from a previous client. Reboot, run the uninstall, and reinstall before digging deeper.

Software update errors

0x87D00668 : software update still detected as actionable after apply

Decimal -2016410008. The update installed, but the post-install scan still reports it as required. Most of the time the machine simply needs a restart before the update is recognised as installed.

C:\Windows\CCM\Logs\UpdatesDeployment.log
C:\Windows\CCM\Logs\UpdatesHandler.log
C:\Windows\CCM\Logs\WUAHandler.log

• Restart the device and trigger a Software Updates Scan Cycle and Deployment Evaluation Cycle from the Configuration Manager control panel applet.
• If it persists, the update is failing silently. Check C:\Windows\Logs\CBS\CBS.log or, for third-party updates, the vendor installer’s own log, and confirm the applicability rules match what the installer actually changes.

0x80072EE2 : the operation timed out

Decimal -2147012894. A WinINet timeout (ERROR_INTERNET_TIMEOUT). In ConfigMgr it normally appears when the Windows Update Agent cannot reach the software update point’s WSUS URL during a scan.

C:\Windows\CCM\Logs\WUAHandler.log
C:\Windows\CCM\Logs\ScanAgent.log

# Test the WSUS endpoint from the client
Invoke-WebRequest http://<SUP FQDN>:8530/ClientWebService/client.asmx -UseBasicParsing

• Confirm port 8530 (or 8531 for HTTPS) is open from the client to the SUP.
• Check proxy settings for the SYSTEM account with netsh winhttp show proxy.
• On the SUP, check the WsusPool application pool in IIS. If it keeps stopping, raise its private memory limit and queue length.

0x87D00692 : group policy conflict

Decimal -2016409966. The ConfigMgr client tried to set the Windows Update server policy to point at its SUP, but a domain Group Policy already sets a different WSUS server, so the scan cannot proceed.

C:\Windows\CCM\Logs\WUAHandler.log

# See which WSUS server is configured
reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate /v WUServer

# See which GPO is setting it
gpresult /h C:\Temp\gp.html

Remove or re-scope the GPO that configures “Specify intranet Microsoft update service location”, or make it point at the same SUP. Run gpupdate /force and a new scan afterwards.

0x87D00667 : no current or future service window exists

Decimal -2016410009. The client has required updates but no maintenance window long enough to install them, so it will never try.

C:\Windows\CCM\Logs\ServiceWindowManager.log
C:\Windows\CCM\Logs\UpdatesDeployment.log

Check which collections the device belongs to and their maintenance windows. Make sure at least one window applies to software updates and is longer than the combined maximum run time of the updates, or set the deployment to install outside maintenance windows.

OS deployment (task sequence) errors

Task sequence errors all land in smsts.log, but the file moves as the deployment progresses. Check each location in turn:

X:\Windows\Temp\SMSTSLog\smsts.log            (WinPE, before disk is formatted)
X:\SMSTSLog\smsts.log                         (WinPE, after disk is formatted)
C:\_SMSTaskSequence\Logs\Smstslog\smsts.log   (full OS, before client install)
C:\Windows\CCM\Logs\Smstslog\smsts.log        (full OS, after client install)
C:\Windows\CCM\Logs\smsts.log                 (after the task sequence ends)

Press F8 in WinPE for a command prompt (enable command support on the boot image first), then launch CMTrace from X:\sms\bin\x64\ if you have added it to the boot image.

0x80004005 : unspecified error in a task sequence

The same generic E_FAIL as above, and the most common task sequence failure code. The step name shown on the error screen and the lines above the failure in smsts.log are what matter.

• Before the task sequence starts: usually no network, wrong system clock or missing NIC or storage drivers in the boot image. Run ipconfig at F8 and check the date.
• During content download: the referenced package is not on a DP the machine can reach. Search smsts.log for “Failed to resolve” or the package ID.
• During Install Application or Run Command Line: the step’s own command failed. Check AppEnforce.log or the program’s log in the location listed above.
• During Apply Network Settings (domain join): check C:\Windows\Debug\NetSetup.log for credential or OU permission problems.

0x80070570 : the file or directory is corrupted and unreadable

Decimal -2147023504. Win32 error 1392 (ERROR_FILE_CORRUPT). It normally appears at the Apply Operating System or Apply Data Image step when the WIM, or a file extracted from it, fails integrity checks.

smsts.log (WinPE location above)

# Check the source image on the site server
dism /Get-WimInfo /WimFile:"\\<server>\source$\OSD\install.wim"

• Validate the WIM with DISM, then update the OS image package on its distribution points so a fresh copy is distributed.
• If only certain devices fail, suspect the target disk or RAM. Run the vendor’s hardware diagnostics.
• If only certain DPs are involved, validate the content on those DPs from the console.

Quick reference table of SCCM error codes

Hex code	Decimal	Meaning	Area	Log to check
0x87D00324	-2016410844	Application not detected after install completed	Applications	AppEnforce.log, AppDiscovery.log
0x87D00607	-2016410105	Content not found	Applications	CAS.log, LocationServices.log
0x87D00213	-2016411117	Timeout occurred (max run time)	Applications and updates	AppEnforce.log
0x80070002	-2147024894	File not found	Applications	AppEnforce.log
0x87D1041C	-2016345060	App not detected after install (Intune)	Co-management	IntuneManagementExtension.log
0x80070005	-2147024891	Access denied	Client install	ccm.log, ccmsetup.log
0x80004005	-2147467259	Unspecified error	Client install and OSD	ccmsetup.log, smsts.log
0x80070643	-2147023293	Fatal error during installation (MSI 1603)	Client install	client.msi.log
0x87D00668	-2016410008	Update still actionable after apply	Software updates	UpdatesHandler.log
0x80072EE2	-2147012894	Operation timed out	Software updates	WUAHandler.log
0x87D00692	-2016409966	Group policy conflict	Software updates	WUAHandler.log
0x87D00667	-2016410009	No current or future service window	Software updates	ServiceWindowManager.log
0x80070570	-2147023504	File or directory corrupted	OSD	smsts.log

Frequently asked questions

Why does the SCCM console show a negative number instead of a hex code?

The console stores error codes as signed 32-bit integers, and any code starting 0x8 has its top bit set, so it displays as negative. Paste the number into CMTrace Error Lookup, or convert it with '0x{0:X8}' -f -2016410844 in PowerShell.

Where is CMTrace if it is not on the machine?

On any device with a current ConfigMgr client it is at C:\Windows\CCM\CMTrace.exe. On the site server it is in the tools folder of the installation directory. For WinPE, copy it into the boot image so it is available at F8.

Does 0x87D00324 mean the application failed to install?

Usually not. The installer returned success, but the detection method could not find the app afterwards. Fix the detection rule first; the software is often already installed on the device.

What should be done when the error code is only 0x80004005?

Treat it as a pointer, not a diagnosis. Open the relevant log in CMTrace, find the 0x80004005 line (it is highlighted in red) and read the entries immediately above it. The failing component, file or command named there is the real problem to fix.