SCCM DP Error - Cannot Create/Open The Remote File

"Cannot write to...." "Cannot create/open the remote file..." "Failed to reopen the remote file..." "Encountered errors while sending SWD package...".  This was the grouping of errors a client was seeing in the "PKGXFERMGR.log" while trying to distribute out a software update.


Now this specific update did get out to other distribution points without issue.  And it appeared to be on its way to successfully transferring to this other random DP without issue.  And then, mid way through the SCCM Console started reporting that it failed to transfer and will be retrying.  After about 4 retries we figured it wasn't correcting the issue on its own and its time to step in.  We checked the "PKGXFERMGR.log" and thats when we saw the errors mentioned earlier.

We remoted to that distribution point and saw the file in question sitting exactly where the logs says it should be (SMS_DP$ with the extremely long file name of "218F6D04CDB2BF29....").  I remembered seeing an article by Prajwal Desai not too long ago that was having a very similar issue, link here http://prajwaldesai.com/sccm-dp-cannot-delete-remote-file-win32-error-5.  In his case the file was trying to be deleted, ours was just trying to "reopen the remote file".  I started to check his suggestions to see if the anti-virus was blocking the file but no such errors in the logs for the anti-virus product.

What was nice was that when it retried to distribute the package again it skipped all the files it already processed, but of course still got stuck on this file.  With that knowledge I decided to simply delete this file under the premise it was corrupt.  While trying to delete it was locked.....I'm assuming it was SCCM locking the file as the anti-virus product reported no such instances of locking the file.  I gave the server a reboot to unlock the file and then I was able to delete it.  When the distribute retry occurred it was able to go through and successfully transfer the file.

As you can see in the log screenshot above, we are getting the "Skip sending content ..." messages on the files it already sent in this software update package (very nice) and now it is successfully retrying to send the file that was locked/corrupted earlier now.  Just something interesting I saw and wanted to share in case someone ran into this similar issue and was curious how to proceed.

Also, if you aren't already checking out prajwaldesai.com then please do.  His article on this helped steer me in a direction, and he has a ton of other great content that is definitely worth a read.