sccm error 0x87d00264 update deployment not yet started

Not specified by the original author.

TL;DR

Error 0x87d00264 means the deployment has not yet started on the client - policy may not have arrived, the available time has not actually been reached in the client timezone, the client is in provisioning or a conflicting state, or evaluation is being suppressed. Confirm the deployment assignment and client policy first, then force a machine policy and evaluation cycle on a test client and watch UpdatesDeployment.log to see whether the deployment is even being processed.

sccm error 0x87d00264 update deployment not yet started

Use this when

• Deployment status shows 0x87d00264 well after the scheduled available time for many clients.
• Clients receive other deployments normally, isolating the problem to this assignment.
• The deployment was set to available in the future, copied with old schedule values, or targeted while clients were offline for a long period.

Not for this skill when

• The deployment is intentionally waiting for its first maintenance window after the deadline. That is expected behavior, not this error.
• The client has no Configuration Manager agent health at all. Repair the client first.

Steps

1. Verify the assignment itself in the console: open the deployment properties and confirm the collection, the available and deadline times, and whether it is required or available. Check the times against your timezone and the client timezone, because a deployment scheduled in a different zone can legitimately not have started yet. Verify: the deployment schedule is confirmed correct in both server and client local time, or the scheduling mistake is found and corrected
2. On a test client, confirm the deployment exists in local policy: run a machine policy retrieval cycle, wait for policy to process, and search PolicyAgent and UpdatesDeployment logs for the deployment unique ID. If the ID never appears, the problem is policy delivery or collection membership, not the update itself. Verify: the deployment ID appears in client policy, or its absence is proven and collection or policy delivery becomes the target
3. Check collection membership and client health for the stuck machines: confirm they are still members of the target collection, the client is active and approved, and no client settings disable software update deployments for them. A silent collection change is a frequent cause of a deployment that never starts. Verify: the test client is an active, approved member of the collection with software updates enabled in its effective client settings
4. Force the software updates deployment evaluation cycle and a scan cycle from the client actions, then read UpdatesDeployment.log forward from that timestamp. The log should show the assignment being evaluated; if it shows suppression due to a maintenance window, provisioning mode, or another deployment in progress, that entry is your answer. Verify: the log shows the assignment evaluated, or names the specific condition suppressing the start
5. Resolve the named suppression: end a stuck provisioning mode, wait out or adjust a blocking maintenance window rule, or repair a client stuck in a previous deployment state by restarting the client service and re-evaluating. Then confirm the deployment moves from not yet started into evaluation, download, or a concrete later state. Verify: the test client leaves 0x87d00264 for a later deployment state, and the same correction is applied to the remaining stuck clients

Why it happens

Not yet started is a pre-evaluation state: Configuration Manager has no record of the client beginning work on that assignment. That happens upstream of everything update-specific - in scheduling, collection membership, policy delivery, or client-side suppression conditions such as maintenance windows and provisioning mode. Because the console code looks identical for all of them, the only efficient path is verifying each link in order with the deployment ID as the tracer, from console assignment through policy arrival to the evaluation log. Recreating the deployment without that trace often reproduces the same state, since the broken link, such as a collection rule or a timezone offset, survives recreation.

Variants and edge cases

0x87d00264 only on newly imaged machines

New clients may still be in provisioning mode or missing their first full policy cycle. Confirm provisioning is complete and the first machine policy has fully processed before judging the deployment.

0x87d00264 after copying an old deployment

Copied deployments carry old schedule and group references. Compare every property of the copy against a known good deployment, especially the software update group version.

0x87d00264 on clients in a different timezone

A deadline set in server time can start hours later than expected for remote sites. Standardize on client local time settings in deployment schedules where the design allows.

Compatibility: Applies to Microsoft Configuration Manager current branch software update deployments to Windows clients.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_xufRUS0mdAYz-jHx2H0zWg

Resolved from the public thread: https://vectle.com/posts/pst_xufRUS0mdAYz-jHx2H0zWg

Thread query: sccm error 0x87d00264 update deployment not yet started

TL;DR: Error 0x87d00264 means the deployment has not yet started on the client - policy may not have arrived, the available time has not actually been reached in the client timezone, the client is in provisioning or a conflicting state, or evaluation is being suppressed. Confirm the deployment assignment and client policy first, then force a machine policy and evaluation cycle on a test client and watch UpdatesDeployment.log to see whether the deployment is even being processed.

Not specified by the original author.

TL;DR

In Configuration Manager, 0x87d01107 on a software update deployment means the client failed during evaluation - typically the update content is not available on an accessible distribution point, the deployment package is stale, or the client cannot evaluate applicability against its update store. Verify content distribution for the deployment package first, refresh the package if needed, then force the client evaluation cycle and read UpdatesDeployment.log for the real sub-error.

sccm error 0x87d01107 software update failed to evaluate

Use this when

• Deployment status shows 0x87d01107 for many machines in one deployment but other deployments work.
• UpdatesDeployment.log or WUAHandler.log on a client shows evaluation failures for the deployment.
• The deployment was created recently, copied from an older one, or its package was modified after assignment.

Not for this skill when

• Machines show a different enforcement error during install. Follow the install-stage code in UpdatesHandler.log.
• The collection has no deployment at all because of a targeting mistake. Fix targeting, not evaluation.

Steps

1. Pick one representative client and collect UpdatesDeployment.log, WUAHandler.log, and ContentTransferManager.log for the deployment window. Find the first 0x87d01107 entry and the lines just before it, which usually name a missing content location, a scan failure, or an applicability problem for a specific update in the group. Verify: the logs name a specific cause such as unavailable content or a failed scan, instead of only the summary code
2. In the console, check the deployment package content status: confirm every update in the software update group is distributed to the distribution points serving those clients and shows as successfully distributed, and redistribute any update showing in progress or failed. Verify: content status shows success for all updates in the group on the relevant distribution points
3. Check the boundary story for the failing clients: confirm their IP ranges or sites map to a boundary group with those distribution points assigned, and that content is allowed from them. Clients outside a boundary group can evaluate a deployment but never obtain its content. Verify: the test client belongs to a boundary group that includes a distribution point holding the content
4. If content is healthy, refresh the deployment: re-run the software updates evaluation cycle on the client from the Configuration Manager control panel or client action, and if many clients share the fault, update the deployment package and re-advertise the deployment so clients receive fresh policy. Verify: the client downloads fresh policy and a new evaluation cycle starts, visible in PolicyAgent.log and UpdatesDeployment.log
5. Watch the test client through evaluation to install or to a clear later error, and only then check the wider deployment compliance. If evaluation now passes but install fails, you have successfully moved the problem to the install stage and should troubleshoot that code instead. Verify: the test client leaves the 0x87d01107 state, either compliant or reporting a specific install-stage result

Why it happens

Configuration Manager update deployment is a chain: policy tells the client what to evaluate, the Windows Update agent scans for applicability, and content must be reachable from a distribution point in the client boundary group. Error 0x87d01107 is reported when that evaluation chain breaks before enforcement, and the console only shows the summary. The break is most often content that was never fully distributed, a stale package after edits, or a boundary gap, all of which are invisible from the deployment status view alone. Reading the client logs to find which link broke, then repairing that link, is faster and safer than recreating deployments blindly.

Variants and edge cases

0x87d01107 on one site only

Site-local failure points at that site distribution point or its boundary group. Compare content status and boundaries against a working site before changing the deployment.

0x87d01107 after editing a software update group

Adding updates without redistributing the package leaves new members without content. Redistribute the package and wait for success status before judging clients.

0x87d01107 with a failed scan underneath

If WUAHandler shows the underlying scan failing against WSUS, fix the client scan health first; deployment evaluation cannot succeed on a broken scan.

Compatibility: Applies to Microsoft Configuration Manager current branch (MECM/SCCM) software update deployments and Windows clients with the Configuration Manager agent.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_39i4uphgbNqbDjRkwVlgZg

Resolved from the public thread: https://vectle.com/posts/pst_39i4uphgbNqbDjRkwVlgZg

Thread query: sccm error 0x87d01107 software update failed to evaluate

TL;DR: In Configuration Manager, 0x87d01107 on a software update deployment means the client failed during evaluation - typically the update content is not available on an accessible distribution point, the deployment package is stale, or the client cannot evaluate applicability against its update store. Verify content distribution for the deployment package first, refresh the package if needed, then force the client evaluation cycle and read UpdatesDeployment.log for the real sub-error.

Not specified by the original author.

TL;DR

0x87d00267 on a ConfigMgr client means the update deployment job failed after content arrived, most often a hash mismatch on a re-downloaded or partially cached package. Check UpdatesDeployment.log and CAS.log on the client, purge the CCM cache for that package, confirm the distribution point copy matches the site source, and redeploy.

sccm software update deployment error 0x87d00267 how to fix

Use this when

• Software Center shows the deployment failed with 0x87d00267.
• The same deployment succeeds on most clients and fails on a subset.
• Failures cluster on clients that interrupted an earlier download.

Not for this skill when

• No clients can get the content and the DP reports errors. That is a distribution problem upstream of the client.
• The client never starts the deployment. Check assignment and maintenance windows first.

Steps

1. On a failing client, read UpdatesDeployment.log and CAS.log in the CCM Logs folder and find the package ID tied to 0x87d00267. Verify: the failing package and its hash or download error are identified
2. Clear that package from the client cache using the Configuration Manager control panel cache settings or the client SDK. Verify: the cached copy is gone and cache space is reclaimed
3. On the site server, redistribute the content to the distribution point and watch distmgr.log until it completes. Verify: content status shows Success for that DP
4. Trigger a software updates deployment evaluation cycle on the client from the Configuration Manager control panel Actions tab. Verify: the client downloads fresh content
5. Confirm the install result in Software Center and UpdatesHandler.log. Verify: the deployment reports Installed or a pending restart, not 0x87d00267

Variant phrasings

sccm 0x87d00267 content hash mismatch

The root-cause phrasing.

software center update failed 0x87d00267

The user-visible symptom phrasing.

configmgr deployment job failed download content

The log-message phrasing from UpdatesDeployment.log.

Compatibility: Compatibility: Configuration Manager current branch clients and distribution points; log locations under the CCM folder.

Why it happens

ConfigMgr verifies downloaded update content against the hash recorded when the package was created. If the source files changed without a proper content update, or a client cached a partial download across a network drop, verification fails and the deployment job is marked with this code even though the network path is healthy.

Edge cases / pitfalls

• Updating content on the site without redistributing leaves DPs serving the old files with new metadata; always pair the two actions.
• Clients on slow VPN links corrupt downloads more often; boundary group and peer cache settings change the failure rate.
• A fleet-wide outbreak after a content edit points at the source files, not at hundreds of client caches.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstHsQC2gGYXjELXmQcZqvYg

Resolved from the public thread: https://vectle.com/posts/pstHsQC2gGYXjELXmQcZqvYg

Thread query: sccm software update deployment error 0x87d00267 how to fix

TL;DR: 0x87d00267 on a ConfigMgr client means the update deployment job failed after content arrived, most often a hash mismatch on a re-downloaded or partially cached package. Check UpdatesDeployment.log and CAS.log on the client, purge the CCM cache for that package, confirm the distribution point copy matches the site source, and redeploy.