14

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.

1 Failed DP Screenshot

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.

MDMoore313
  • 5,531
  • 6
  • 34
  • 73
  • 1
    I would start by reviewing the built-in report under found under the Software Updates - E Troubleshooting category. – Garth Jones Jun 27 '14 at 12:24
  • Have you checked the logs in the clients themselves? The one I usually start with is $env:windir\ccm\logs\wuahandler.log Look for the lines with ERROR and WARNING flags. An update will look like this (I am going off my head; don't have a windows machine to cut-n-paste) 1) Tell it is about to start update. This part takes lots of lines because they want to make it look pretty 2) Say who is the SCCM server it is getting the files 3) Mention that it is checking files and which packages if any it is getting 4) If it sees an error, it will report like "I cannot get a package" or "I cannot find the – raubvogel Apr 28 '15 at 10:45
  • -1, this is a client causing this problem more than likely, but individually perusing 3000 clients for logs indicating something that should already be known to the distribution point is insane. I know what to expect, this is not a question that requires a vague answer, or even a question that can benefit from a vague answer. It's a very specific question. – MDMoore313 Apr 28 '15 at 11:10
  • If he has SCCM admin access, he should be able to go to the monitoring->deployments, and then find the entry for the software package there. Clicking on that will show which clients had that installed and which didn't. I assumed the image he got came from that screen. – raubvogel Apr 28 '15 at 13:51

2 Answers2

3

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.

TallPaul
  • 31
  • 3
  • +1 for the log info, but the issue is that the server cannot copy the files yes, but our working theory is that a client has a write-lock on the DP files somehow. Folder structure isn't too long b/c this particular package had the files already zipped, and the behavior isn't consistent but spotty. – MDMoore313 Oct 01 '15 at 16:20
0

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

Super1337
  • 474
  • 2
  • 4
  • 9
  • 2
    would you be able to go into a little more detail as to *how* someone would use the toolkit to find a client still holding onto a package? If not, this is effectively a link only answer, as I already had the toolkit installed. – MDMoore313 Jan 23 '15 at 14:21