It happens from time to time. I update a package and need to update the distribution point. We have multiple DPs, and usually everything goes through fine, however every once in a while, our main DP fails to update the package.
The content status log never says much about the failure. I don't have backend server access to the management points, or the DPs, I'm just the SCCM admin. I can check any logs in SCCM, run reports, and everything, but I don't know where to look.
In the past I've tried setting the "Disconnect Users from Distribution Point" setting on the problem package, both sub-settings to 0, but it doesn't really work for us. The problem just seems to go away on it's own after some time, but sometimes it takes several days. For the majority (really all, but there may be one or two I've overlooked) we set clients to "Run Program from Distribution Point" When deploying the program, not sure if that has anything to do with it, or what the root cause is.
Update
I've found a little more information in the reports, specifically the All Status Messages for a Specific Package at a Specific Site query. Using my package ID for the query, after the DP Update failed again, I did see one entry that stood out:
Distribution Manager failed to process package "Configuration Updates" (package ID = SOM00013).
Possible cause: Distribution manager does not have access to either the package source directory or the distribution point. Solution: Verify that distribution manager can access the package source directory/distribution point.
Possible cause: The package source directory contains files with long file names and the total length of the path exceeds the maximum length supported by the operating system. Solution: Reduce the number of folders defined for the package, shorten the filename, or consider bundling the files using a compression utility.
Possible cause: There is not enough disk space available on the site server computer or the distribution point. Solution: Verify that there is enough free disk space available on the site server computer and on the distribution point.
Possible cause: The package source directory contains files that might be in use by an active process. Solution: Close any processes that maybe using files in the source directory. If this failure persists, create an alternate copy of the source directory and update the package source to point to it.
I'm doubting the middle two causes for simple reasons
The source folder isn't that deep to contain long filenames for NTFS, although I'll attempt to check for completeness.
I can add files to the DP just fine, so it's not a filespace problem, other packages can be updated just fine.
What I wasn't expecting is that the 3rd cause says the source directory is in use somewhere. What difference would that make anyway? Isn't is just copying the files off the fileshare into the SCCM DP Share? Further throwing me for a loop b/c clients don't even access the source directory, it's pretty much just a staging directory for sccm to copy files from.
That just leaves the first cause, but that again goes back to the same thing: Other packages can update just fine.
I doubt you'll be able to resolve this if this is true "I don't have backend server access to the management points, or the DPs".
Can you access the distmgr.log on the site server? If not, then you will need to escalate the issue to someone who can.
This issue is nothing to do with the client so I would ignore other answers advising to look at the clients. This issue is caused because the Site Server cannot copy the files from your source folder to the distribution point.
If you can't access the Site Server logs, one thing you could try to eliminate it being down to your folder structure being too long is to zip up your package, deploy it, and unzip before installing at the client end.
Get the SCCM toolkit. It has a log analyzer and distribution point tool kits that can help you find the problem.
http://www.microsoft.com/en-us/download/details.aspx?id=36213