Hi All, i just wanted to ask if anyone else had experienced this issue yet?

We have ~200 Pull DP's and for some time have been having issues with OSD Task Sequences randomly failing with the error 80070002.
More specifically:

Invalid path. \\server\share format needed
..
Failed to find an available source location

Our Task sequence is configured to access content directly from the DP.  We checked the PackageShare$ and validation state and both were fine.  Next we inspected WMI (root\sccmdp:SMS_PackagesInContLib) and this was fine as well.  Until today, we had been redistributing the failing package to remediate, but this is very time consuming with some of the large WIMs and Driver Packages, especially over some very slow WAN links.

Today I decided to explore this a little further by examining the Database..This led me to the table ContentDPMap and the two columns in particular 'URL' and 'URLSubPath'.
I noticed that the packages we were having issues with had a URL of the ServerName in UNC format, and a URLSubPath of just '\'.  Other packages had a fully qualified UNC path to the package for URL and a full sub path for URLSubPath.

When we queried the DB further, we revealed 1190 packages to be in this state (for packages supposed to be in the share) out of a total of 42,000 records.

The query we used for this was:

select ContentID,ServerName,AccessType,URL,URLSubPath,URLProtocol,vpkg.Name from ContentDPMap as cdpm
join v_Package as vpkg on vpkg.PackageID = cdpm.ContentID
where cdpm.AccessType = 2 --UNCProtocol
and cdpm.URLSubPath not like '%SMS%' --Packages with issues only have a '\'
and vpkg.PkgFlags = (vpkg.PkgFlags | 0x80) --Limit to only show packages with the 'Copy To Package Share' flag set

Also of note, when a package is marked with a State = 2 the values for URL/URLSubPath are NULL. (State =2 is In Progress).

So my question:
Firstly, has anyone else encountered this?
Secondly - how should I fix it - we tested in our DEV and found that updating the entries remediates the issue with Clients not being able to locate content, but realise this is is an unsupported method.

I will also log this on Connect as it appears to me to be a Bug.

Cheers,

David

Our Task sequence is configured to access content directly from the DP.  We checked the PackageShare$ and validation state and both were fine.  Next we inspected WMI (root\sccmdp:SMS_PackagesInContLib) and this was fine as well.  Until today, we had been redistributing the failing package to remediate, but this is very time consuming with some of the large WIMs and Driver Packages, especially over some very slow WAN links.

Hi,

So redistributing the failed package could resolve this issue?

How about using prestaged content to distribute these large contents?

Best Regards,

Joyce

Hi Joyce, thanks for taking the time to help out.

Redistributing the package sometimes works, but we have had occasions where we have had to do it multiple times, so is not a reliable workaround.

We could potentially use prestaged content to get the larger packages out there, but this adds a lot of extra work to the otherwise simple task.

I'm not sure that many others are using Pull DP's on the same scale that we are - but would love to hear from anyone with a few if they could run the above sql query to determine if they have a similar issue to us.

Regards,

David

An update on this issue:

We have upgraded to CU2, and the issue is still present.  I haven't tested thoroughly but I believe the issue occurs most frequently when distmgr receives a large number of responses at a time.

For example, just now we distributed two drive packages, both around 700MB to 220 PullDP's.  The first few DP's to complete recorded their entries fine in the DB.  When a large batch returned their results, the DB was inundated with broken entries.

We devised an update query to remediate the issue as follows:

(Where SMSPKGM$ is our package share path - All our PullDP's have the same configuration)

update ContentDPMap
set
URL = URL + 'SMSPKGM$\' + ContentID + '\',
URLSubPath = '\SMSPKGM$\' + ContentID + '\'
from
ContentDPMap as cdpm
join v_Package as vpkg on vpkg.PackageID = cdpm.ContentID
where cdpm.AccessType = 2
and cdpm.URLSubPath not like '%SMS%'
and vpkg.PkgFlags = (vpkg.PkgFlags | 0x80)

I'd love to hear from anyone else that is having issues like this.

I've figured out the same behaviour, but it seems that the Value of URL and URLSubPath is only filled out when the option "Copy the content in this package ot a package share on distribtuion points:" is set.

Otherwise the Pkg is not located on the FileShare so no patch is set in the Database

Can you please give this a try?

Hi, Yes, it is true that these values are only set when the check box is checked for 'copy content to package share'

All our packages that require to be located in this share have this box checked.

We have upgraded to R2 SP1 and still have this behaviour in our environment.  It also appears that it isn't only large packages that have the issue but small ones as well <10MB.

Another thing I have noticed is that it only occurs when we distribute content to a large number of DP's at once.  My guess is that the DP's all respond within a small window and overwhelm the distributionmanager and cause it to not process all the updates correctly?

I have a workaround, as above, but it isn't ideal. (redistributing also works, but on larger packages is less than idea)