Content for one package won't distribute when attempting to "Update distribution points"

We have had a hard time since day one with AutoCAD.  We have mostly been able to distribute everything without issue, except for AutoCAD.

The first thing I will say that I don't understand is that I have never, ever assigned any permissions to the software share, but it has never had problems distributing or deploying.  I thought that's what the network access account was for, but evidently not.  I run the effective permissions on multiple folders containing software we distribute and deploy, but am yet to find anything that gives even read rights to my network access account, or my site server(s), or distribution points, or anything.  So that is a mystery to me.

Today, however, my problem has increased substantially.  I had to distribute the AutoCAD package via prestaged content files in order to get it to distribute properly.  Now that it has been sitting happily on my distribution points for a couple of months, a desktop admin made an update to the package and attempted to update the distribution points.  We both assumed that the only thing that updates are the changes.  They all went immediately to failed, except for the local site server that the data actually exists on (it is a distribution point and the primary site).  

I look at the PkgXferMgr.log and I see a ton of messages that say "Abandoning send request because address is not available at this time".  It is also full of errors that say "Send request XXXXXX is skipped for site" for every distribution point I have.  Now, we do have a rule in effect that distributions will not occur during business hours, but when I try to deploy a different package it is at least sitting in "In progress" rather than failed.  I should also add that once the package's status went to failed, this is what the error read;

"Distriubtion Manager failed to access the source directory \\blah\blah\blah" for content "AutoCAD 32bit"
Possible cause: Distribution Manager does not have sufficient rights to the source directory.
Solution: Verify that the site server computer account has at least Read access to the directory you specify as the source directory.
Possible cause: There is not enough disk space available on the site server.
Solution: Verify that there is enough free disk space available on the site server."

In the past, even when it seemed to have transferred properly, it has always filled with errors like this;
"Not copying: AdminImag\x86\acadmap\Program Files\Common Files\Autodesk Shared\GIS\ImportExport\9.1\tcl_library\grammar_peg\peg_interp.tcl"

If anyone can help I would appreciate it very much.

October 30th, 2012 7:40pm

"Distribution Manager failed to access the source directory \\blah\blah\blah"

Have you verified that the site server itself can locate and access this path and all of its content?

Free Windows Admin Tool Kit Click here and download it now
October 30th, 2012 8:25pm

Thanks for the quick reply. 

I have remoted into 2 of the distribution points just to make sure they have no problem finding the path (with me logged in) and there was no problem browsing to the location and sifting through the folder, subfolders, etc.  Is there another way for me to do it that isn't using my user rights?

October 30th, 2012 8:31pm

Why are *you* logging in or even remoting in? Also, this has nothing to do with the DPs, it has to do with the source file location.

Thus, you need to try to access \\blah\blah\blah from the site server using the site server's account just like the site server is doing; i.e., Have you verified that the site server itself can locate and access this path and all of its content?

Free Windows Admin Tool Kit Click here and download it now
October 30th, 2012 9:05pm

At the risk of sounding stupid, I don't know how to attempt to locate the source files using the site server's computer account.  Can you explain?
October 30th, 2012 9:29pm

First, you need to be logged onto the site server with a local admin account.

Next, you'll need psexec so that you can run a process as the local system. Running the following will pen a new command-prompt as the local system:

psexec -s -i cmd.exe

Then, from this new command-prompt (running as the local system), you can try to navigate and see into the source directory: dir \\blah\blah\blah

Free Windows Admin Tool Kit Click here and download it now
October 30th, 2012 9:54pm

Thanks Jason, here are my results.

Since I'm unaware of any other method to browse to a network share within a command prompt, I attempted to map the AutoCAD folder as well as some other software folders and was unsuccessful using the system account (system error 55).  I used my own administrator account and had no problem.  I then attempted to browse to a drive that I mapped using my own account and was also unsuccessful.  Therefore, it appears that the system account for this site server is unable to get to this folder.  I will say that using the system account I was able to carry the main folder (\\sccmserver\software) just not the 3 subfolders under it. 

What strikes me about all of this, though, is that I've really only had 1 package that I have consistently had trouble with, and that's AutoCAD.  So I'm not sure why I can't access those folders.  Also, I pushed another application this evening to a server without error, and I had the same result when attempting to map to the folder it came from - system error 55. 

So, you're the expert of course, but it seems to me that the system accounts just simply don't have access.  Is it possible that another account is being used to access the files?  Should I perhaps consider giving Authenticated Users read access?

October 31st, 2012 3:35am

First, *everyone* has problems with AutoCAD in ConfigMgr because of the number of files, size of the install, and number of subfolders.

Error code 55 = "The specified network resource or device is no longer available."

This most likely means that the directory path is too long/has too many characters in it.

You can try shortening the path and updating it in ConfigMgr and see if that works.

Free Windows Admin Tool Kit Click here and download it now
October 31st, 2012 3:10pm

I was able to use the exact same command to do the same thing when not using the system account.  It only errored when using the system account.  And the path isn't that long \\1234567890\12345678\1234567 - 25 characters long total, not including slashes.
October 31st, 2012 7:57pm

I'm out of ideas for this specific error. You can try re-propagating permissions on this path and its subfolders and files to make sure there isn't something wonky there.
Free Windows Admin Tool Kit Click here and download it now
October 31st, 2012 8:15pm

Is there any way for me to figure out what account is actually being used to access the shared folders to distribute?  My desktop admin rebuilt the package last night and tried distributing it and we're getting the same problem.  Don't know why this is all of a sudden a problem.
November 1st, 2012 1:23pm

It's the computer account of the site server system. Using psexec to run a command prompt as the local System account allows you to use this account.
Free Windows Admin Tool Kit Click here and download it now
November 1st, 2012 1:56pm

 That's what I thought.  All of the software is sitting on the primary site server and SYSTEM has full control.  The site server is also an administrator on all of the SCCM DPs via GPO.  So, yeah, looks like I'm stuck.  Thanks for your help.
November 1st, 2012 2:56pm

I don't think your issue is permissions at this point, as mentioned, everyone has issues with AutoCAD. But for edification, because the site server is using a UNC to access the content, the actual computer account for the site server needs share permissions also as SYSTEM has no context on the network.
Free Windows Admin Tool Kit Click here and download it now
November 1st, 2012 3:08pm

The data exists on the site system itself, is what I meant.  And the system account for the primary site server that holds the data is an admin on all of the DPs.
November 1st, 2012 5:29pm

I want to mention that we are having the same behavior, but with some packages that has only a dozen of small files...

We have redistributed the package to our SCCM infrastructure as follow:

  • We have 1200 DP's spread across 6 secondary sites
  • The behavior is occurring not only on 1 package, but it depends per DP... Mostly the same package is coming back several times, but it is not only limited to just 1 package
  • We also have migrated Server 2003 DP's to Server 2008R2 with Prestaged content

For us this is more like "normal" behavior: the packages are configured to be distributed only at night. Since we have such amount of DP's, there is a huge list to process.

We assume that it is because of the huge list that SCCM is sometimes showing the same message as above.

Eventually (after let's say a weekend) most of the packages are transferred...

Free Windows Admin Tool Kit Click here and download it now
May 7th, 2015 8:46am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics