Fix SCCM Update Error 0x87d00664: Complete Troubleshooting Guide

Your SCCM console shows a sea of red error codes, and 0x87d00664 is the one ruining your Tuesday morning. You're not alone—this is one of the most common software update deployment failures in ConfigMgr environments. The good news? It's almost always fixable.

I've spent the better part of fifteen years working with Configuration Manager, and this particular error has crossed my desk more times than I can count. It's appeared on Windows 10 workstations, Windows Server 2019 boxes, and even in environments running the latest Windows Server 2025 builds. The error code 0x87d00664 sccm update failures affect all of them, and the root cause varies more than you might expect.

What makes this error particularly frustrating is that it doesn't point to a single, obvious problem. It's like a check engine light—it tells you something's wrong, but not exactly what. This guide walks you through a systematic approach from diagnosis to resolution, covering the multiple root causes I've encountered: timeout issues, distribution point problems, and third-party software conflicts.

---

What Does SCCM Error 0x87d00664 Mean?

Before we dive into fixes, let's understand what we're actually dealing with. The error code 0x87d00664 translates to "Updates handler job was cancelled." In plain English, the client-side update installation job was interrupted or terminated before it could complete successfully.

Understanding the Error Code and Its Decimal Equivalent

You might see this error displayed in a couple of different formats. The hexadecimal form 0x87d00664 is what shows up in the SCCM console and Software Center. But if you're digging through log files or writing PowerShell scripts to query update status, you'll likely encounter the decimal equivalent: -2016410012.

According to Microsoft's error code documentation, this is a client-side error. That's an important distinction—it means the problem isn't with your SCCM infrastructure itself, but with what's happening on the individual client machines. The update job was started, but something caused it to be cancelled before it finished.

Common Scenarios Where This Error Appears

In my experience, this error shows up in three recurring scenarios:

Software Center update installations failing on Windows 10/11 workstations. This is the most common scenario. Users see the update stuck in "Installing" status, then it flips to "Failed" with error 0x87d00664. The update might have actually installed in the background, but SCCM lost track of it.

Windows Server 2019/2022/2025 cumulative update deployments. Server environments present their own challenges. I've seen this error frequently when deploying large cumulative updates to servers with limited maintenance windows. The update simply doesn't finish within the allotted time.

Updates that appear installed but are still reported as failed by SCCM. This is the sneaky one. The update actually installed successfully, but because the SCCM client job was cancelled, it never reported the successful result back to the site server. The update shows as failed in the console, but when you check the client, the update is present.

A quick scan of IT forums like r/SCCM and the Microsoft Tech Community shows this error appearing across all these scenarios with surprising frequency. It's not tied to a specific OS version or update type, which is why a systematic troubleshooting approach is essential.

---

Root Causes Behind SCCM Update Error 0x87d00664

Over the years, I've narrowed down the root causes of this error to three main categories. Understanding these will save you hours of frustration.

Update Timeout and Maximum Runtime Settings

The most common culprit, and the one I check first, is the maximum runtime setting for software updates. Every update in SCCM has a configured maximum runtime—the amount of time the system will track the installation before giving up.

Here's the thing: the default maximum runtime for most updates is 10 minutes if you did a fresh install of Configuration Manager version 1511 or higher, and 5 minutes if you upgraded from a previous version. Service packs get 60 minutes by default. But large cumulative updates for Windows 10 or Windows Server can easily take longer than that, especially on older hardware or heavily loaded systems.

When an update exceeds its maximum runtime, SCCM stops tracking it and reports a failure. The installation might continue in the background and eventually succeed, but SCCM won't know about it. This is exactly what produces the 0x87d00664 error.

Maintenance windows add another layer of complexity. If your maintenance window is shorter than the maximum runtime, the update won't even start. If it's only slightly longer, the update might get cancelled mid-installation when the window closes.

To check the maximum runtime for an update, open the SCCM console, navigate to Software Library > Software Updates > All Software Updates, and add the "Maximum Run Time (Mins)" column to your view. You can also right-click an individual update, select Properties, and check the Maximum Run Time tab.

Distribution Point and Content Download Issues

The second major cause is content-related. The client needs to download the update content from a distribution point before it can install. If that download fails or is incomplete, the update job gets cancelled.

I recall a case from a few years back where a client environment had this exact issue. The content was present on the distribution point—we verified it in the content library, confirmed it was distributed correctly, everything looked good on the server side. But clients were still failing with 0x87d00664. The problem turned out to be that clients couldn't access the distribution point due to boundary group misconfigurations.

Boundary groups determine which distribution points a client can use. If a client isn't in a boundary group that includes a distribution point with the content, it can't download the update. The download hangs, the job times out, and you get the error.

Another issue I've seen is corrupted content on the distribution point. The content library might show the files as present, but they're actually incomplete or corrupted. This usually happens after an interrupted content distribution or a disk issue on the DP.

Third-Party Security Software Interference

This is the one that catches most people off guard. Third-party security software can silently block update downloads or installations, causing the SCCM update job to be cancelled.

The most memorable case I encountered involved CyberArk Endpoint Privilege Manager (EPM). The client had verified everything—logs looked clean, content was on the DP, boundaries were configured correctly. But updates kept failing with 0x87d00664. After digging into the CyberArk EPM logs, we found that it was blocking the download of the update files. Once we adjusted the EPM settings to allow the downloads, the updates installed without issue.

This isn't unique to CyberArk. I've seen antivirus software quarantine update files mid-download, application whitelisting tools block the update installation process, and even endpoint detection and response (EDR) tools interfere with the Windows Update agent.

The tricky part is that these tools don't always log their actions in obvious places. You might need to check the security software's own logs alongside the SCCM log files to spot the interference.

---

Step-by-Step Diagnosis: How to Check SCCM Log Files for 0x87d00664

When I'm troubleshooting this error, I always start with the log files. They tell the story of what happened, and they'll point you toward the right fix. Here's what to look for.

Key Log Files to Examine: WUAhandler.log, UpdatesHandler.log, UpdatesDeployment.log

Three log files are critical for diagnosing software update issues on SCCM clients. They're all located in C:\Windows\CCM\Logs on the client machine.

Interpreting Related Error Codes: 0x80240022 and 0x87d00215

When you're digging through the logs, you'll likely encounter related error codes that help narrow down the root cause.

0x80240022 means "Operation failed for all updates." This typically appears in WUAhandler.log and indicates that the Windows Update Agent couldn't process any of the updates in the job. This often points to a broader issue with the Windows Update Agent itself, or with the update metadata.

0x87d00215 means "Item not found." This appears in UpdatesDeployment.log and usually indicates that the content couldn't be downloaded from the distribution point. The client couldn't find the content it needed, so the update job was cancelled.

Here's how I use these codes in practice: if I see 0x80240022 in WUAhandler.log, I focus on the Windows Update Agent and update metadata. If I see 0x87d00215 in UpdatesDeployment.log, I focus on content distribution and distribution point access. The combination of these codes with 0x87d00664 tells you where to look next.

---

Proven Fixes for SCCM 0x87d00664 Software Center Errors

Now let's get to the fixes. I've organized these from the most common solution to the more drastic ones. Try them in order.

Fix 1: Adjust Maximum Runtime for Software Update Deployments

This is the fix I apply most often. If the maximum runtime is too short for the update to complete, you need to increase it.

Here's how to do it:

1. Open the SCCM console and navigate to Software Library > Software Updates > All Software Updates.
2. Find the update that's failing. You can search by the KB number or the update name.
3. Right-click the update and select Properties.
4. Go to the Maximum Run Time tab.
5. Enter a new value in minutes. For cumulative updates, I typically recommend 60 minutes. For larger updates or slower networks, you might need 120 minutes.

One important caveat: if the update was already deployed, changing the maximum runtime won't take effect for existing deployments. You'll need to remove the deployment and create a new one. This is a known limitation that Microsoft documents in their configuration guide.

For ongoing management, you can also set default maximum runtime values for different update types. In the SCCM console, go to Administration > Site Configuration > Sites, right-click your site, select Configure Site Components > Software Update Point. On the "Maximum Run Time" tab, you can set defaults for different update categories.

Fix 2: Run ccmrepair.exe to Reinstall the SCCM Client

If the issue isn't related to runtime settings or content, the SCCM client itself might be in a bad state. This can happen after a failed client update, a corrupted policy, or a botched uninstall/reinstall.

The ccmrepair.exe tool repairs the SCCM client without a full uninstall. It's less disruptive and usually faster.

Here's the process:

1. Open an elevated command prompt on the affected client.
2. Navigate to C:\Windows\CCM.
3. Run ccmrepair.exe as Administrator.
4. Wait for the repair to complete. This can take several minutes.
5. Restart the client machine.
6. In the Configuration Manager control panel applet, trigger the Machine Policy Retrieval & Evaluation Cycle, User Policy Retrieval & Evaluation Cycle, Application Deployment Evaluation Cycle, Software Updates Scan Cycle, and Software Updates Deployment Evaluation Cycle.

I've seen this fix work in cases where the client's update state was corrupted. The repair resets the client components while preserving the client's unique identifier and site assignment.

If ccmrepair.exe doesn't work, you can do a full client uninstall and reinstall. This is more drastic but sometimes necessary. Uninstall the client via Control Panel or ccmsetup.exe /uninstall, then reinstall using ccmsetup.exe with your site's installation parameters.

Fix 3: Manually Install the Failed Update as a Workaround

Sometimes you need to get the update installed now, and you can deal with the root cause later. In these cases, manually installing the update is a viable workaround.

First, identify the specific update from the SCCM logs. In UpdatesDeployment.log, search for the update ID associated with the 0x87d00664 error. The log entry will look something like this:

Update (Site_E9267BCB-2995-4BF8-8CC8-A8CB5064F44C/SUM_6b5fa06e-2bec-411b-a3b0-bfb10bf50240) Progress: Status = ciStateError, PercentComplete = 0, DownloadSize = 0, Result = 0x87d00664

The GUID after "SUM_" is the update's unique identifier. You can use this to find the corresponding KB article in the SCCM console or via a SQL query against the site database.

Once you've identified the KB number, download it from the Microsoft Update Catalog and install it manually on the affected clients. This is a temporary fix—you'll still want to resolve the underlying issue to prevent future failures—but it gets the update installed and the client compliant.

---

Advanced: Resolving 0x87d00664 on Windows Server 2025 and Newer Environments

Server environments present their own set of challenges, and Windows Server 2025 has introduced some new wrinkles.

Specific Considerations for Server 2025 and KB5065426

There have been recent forum reports of 0x87d00664 errors when applying KB5065426 on Windows Server 2025 build 26100.1742. This is a cumulative update, and it's a large one. The size alone can cause timeout issues if your maximum runtime settings haven't been adjusted.

In the sysnative.com forum thread discussing this issue, several administrators reported that the update failed with 0x87d00664 even though the maximum runtime was set to 60 minutes. The common thread was that the servers were running other workloads that competed for resources during the update installation window.

For server environments, I recommend a few additional steps:

1. Increase the maximum runtime to 120 minutes for large cumulative updates on servers.
2. Schedule updates during off-peak hours when server workloads are minimal.
3. Monitor server resource usage during update installation. If the server is CPU or disk-bound, the update will take longer.

WSUS Synchronization Issues and Their Impact on Update Deployments

WSUS synchronization problems can cause a cascade of issues that eventually manifest as 0x87d00664 on clients. If the WSUS server hasn't synchronized properly, the update metadata in SCCM might be incomplete or outdated. Clients then try to download updates based on this incomplete metadata, fail, and the job gets cancelled.

Here's a quick checklist for verifying WSUS health:

• Check WSUS synchronization status in the SCCM console under Monitoring > Software Update Point Synchronization Status.
• Verify that the last synchronization was successful and completed without errors.
• Check the WSUS server's event logs for synchronization errors.
• If synchronization has failed, force a re-synchronization by right-clicking the Software Update Point in the console and selecting "Synchronize Software Updates."

I've seen environments where WSUS synchronization hadn't run successfully for weeks, and clients were failing with a variety of update errors, including 0x87d00664. Once the synchronization was fixed and the metadata was updated, the errors resolved.

---

Preventing SCCM Update Deployment Errors: Best Practices for 2026

An ounce of prevention is worth a pound of cure, especially in SCCM environments. Here are the practices I recommend to minimize update deployment failures.

Optimizing Boundary Groups and Distribution Point Configuration

Boundary groups are the backbone of content distribution in SCCM. If they're not configured correctly, clients can't find the content they need, and you'll see download failures.

Microsoft's documentation on boundary groups is thorough, but here are the key points I emphasize:

• Design boundary groups around your network topology. Group boundaries that reflect your actual network segments, not arbitrary organizational divisions.
• Configure fallback behavior carefully. Fallback to a different distribution point is useful, but it can cause issues if the fallback DP doesn't have the content. Make sure all DPs in a boundary group have the same content.
• Regularly verify content distribution. Use the "Distribute Content" wizard to check that content is present on all DPs. The Content Library Explorer tool is also useful for this.

Monitoring and Alerting for Update Deployment Failures

You can't fix what you don't know about. Setting up monitoring and alerting for update deployment failures will help you catch issues early.

SCCM has built-in reports that track update compliance and errors. The "Compliance 1 - Overall Compliance" report and the "Compliance 5 - Specific computer" report are good starting points. For error tracking, the "Compliance 9 - Overall health and compliance" report shows error codes for failed updates.

For proactive monitoring, I recommend setting up SCCM console notifications for deployment failures. You can configure these under Monitoring > Alerts in the console. You can also use Power BI to create custom dashboards that track error codes across your environment.

On the client side, tools like CMTrace (now part of the Configuration Manager console) are essential for reviewing log files. Third-party log monitoring tools can also help you spot patterns before they become widespread issues.

---

Frequently Asked Questions

What does SCCM error 0x87d00664 mean?

SCCM error 0x87d00664 translates to "Updates handler job was cancelled." It indicates that the update installation job on the client was interrupted or terminated before it could complete. This is a client-side error that typically occurs due to timeout settings, content download failures, or interference from third-party security software.

How do I check SCCM logs for error 0x87d00664?

Three key log files contain information about this error, all located in C:\Windows\CCM\Logs on the client machine. WUAhandler.log records Windows Update Agent activity, UpdatesHandler.log records compliance scanning and update installation, and UpdatesDeployment.log records deployment activation and enforcement. Search these logs for the error code 0x87d00664 or related codes like 0x80240022 and 0x87d00215.

Can WSUS issues cause SCCM error 0x87d00664?

Yes. WSUS synchronization problems can lead to incomplete or outdated update metadata in SCCM. When clients try to download updates based on this incomplete metadata, the download fails and the update job gets cancelled, resulting in error 0x87d00664. Verify WSUS synchronization status and force a re-synchronization if needed.

Does reinstalling the SCCM client fix error 0x87d00664?

Sometimes, yes. Running ccmrepair.exe or reinstalling the SCCM client can resolve issues related to corrupted client state or policies. However, it's not a guaranteed fix if the root cause is infrastructure-related, such as distribution point misconfigurations or WSUS synchronization issues. Always check the log files first to identify the underlying cause.

---

Conclusion

The 0x87d00664 sccm update error is frustrating, but it's rarely a dead end. In my experience, most cases boil down to one of three causes: maximum runtime settings that are too short, distribution point or content issues, or third-party security software interfering with the update process.

The key is to approach it systematically. Start with the log files—they'll tell you what happened. Then work through the fixes in order: adjust the maximum runtime, verify content distribution, check for security software interference, and only then consider client repair or reinstallation.

I've seen environments where this error plagued them for weeks, only to be resolved by a simple maximum runtime adjustment. I've also seen cases where the fix required digging into third-party security software logs to find the root cause. The common thread is that a systematic approach always wins.

If you're still facing this error after trying these solutions, share your log file findings in the comments below—our community of SCCM experts is here to help. And don't forget to subscribe for more ConfigMgr troubleshooting guides.