I have two packages that are distributed to four distribution points in a single distribution point group. Every Sunday when content validation runs, the two packages continue to fail content validation only on one of the four distribution points. The package is configured to copy the content to a package share on the distribution points.

The package has been deleted and recreated, but it still continues to fail content validation. An interesting note is that when the packages are not configured to copy the contents to a package share on the distribution points, they pass content validation.

When content validation does fail (when copy the content is set), the SMSDPMON log shows the following bad news.

[Package A]

CreateFileW failed for \\SCCM_SITE_SERVER\smspkgd$\ps10058e\eclipsec++\features\org.eclipse.linuxtools.cdt.libhover.devhelp.feature_1.0.0.201309171939\meta-inf\maven\org.eclipse.linuxtools.cdt.libhover\org.eclipse.linuxtools.cdt.libhover.devhelp.feature\pom.properties               SMS_Distribution_Point_Monitoring         7/30/2015 2:54:59 PM    4152 (0x1038)

FileOpen failed; 0x80070003        SMS_Distribution_Point_Monitoring         7/30/2015 2:54:59 PM               4152 (0x1038)

CSMSContentUtils::EvaluatePackageShare: Failed to compute hash for content PS10058E.2               SMS_Distribution_Point_Monitoring         7/30/2015 2:54:59 PM    4152 (0x1038)

[Package B]

CreateFileW failed for \\SCCM_SITE_SERVER\smspkgd$\ps10058c\eclipse\features\org.eclipse.recommenders.feature.completion.rcp.intellig_1.0.4.v20130612-1006-b77\meta-inf\maven\org.eclipse.recommenders\org.eclipse.recommenders.feature.completion.rcp.intellig\pom.properties               SMS_Distribution_Point_Monitoring         7/30/2015 3:53:47 PM    5284 (0x14A4)

FileOpen failed; 0x80070003        SMS_Distribution_Point_Monitoring         7/30/2015 3:53:47 PM               5284 (0x14A4)

CSMSContentUtils::EvaluatePackageShare: Failed to compute hash for content PS10058C.2               SMS_Distribution_Point_Monitoring         7/30/2015 3:53:47 PM    5284 (0x14A4)

My assumption is that the content library might be jacked. I am thinking that I might have to rebuild the distribution point. Does anyone have any other suggestions for troubleshooting and rectifying this situation? Is there a way to rebuild the content library without rebuilding the distribution point? The error code 0x80070003 mentioned above, suggests the system cannot find the path specified. I have verified both paths exists... Whatever is occurring is beyond me.

-Tony

• Edited by Tony Chirillo Thursday, July 30, 2015 9:12 PM

Torsten

I made two new packages with out the two files and validation happens successfully. Also, I am not sure what happened over night, but now the original packages fail validation on all 4 distribution points. Even the duplicate packages  I made with the questionable files.

-Tony

Hi,

Have you resolved this problem?

No I have not. I am going to put this package in my lab environment to see if I can reproduce the problem there. -Tony

I built one of the packages in my lab environment, and that package passes content validation as expected. In production, I am assuming that something could be damaged in the content library causing both packages to continue to fail content validation on all four of the DP's...

Both of these two packages have quite the nested package structure. According to Word, the path to Package A is 261 characters, 262 with the terminator. Could this be causing problems? If memory serves me correctly, there is a 255 character limit, but I am not sure if SCCM is smart enough to deal with longer paths. Can anyone confirm or deny this? I have a theory that could be the issue. I actually stumped across this today, but wanted to get some other perspectives.

In the meantime, I am going to try to move the file closer into the start of the path to try to prove my theory. 

-Tony

• Edited by Tony Chirillo 15 hours 43 minutes ago
• Marked as answer by Tony Chirillo 11 hours 34 minutes ago

PkgSourcePath is nvarchar(255) in the database, so yes it's limited. 

Too bad you modified "\\SCCM_SITE_SERVER\smspkgd$\ps10058c\eclipse\features\org.eclipse.recommenders.feature.completion.rcp.intellig_1.0.4.v20130612-1006-b77\meta-inf\maven\org.eclipse.recommenders\org.eclipse.recommenders.feature.completion.rcp.intellig\pom.properties" to hide your servername... path length came to my mind earlier, but that string is 258 long and I assumed that the real servername is a bit shorter ...

I verified that this was the issue. I created a new package and adjusted the source where the pom.properties files was located sooner in the path. This allowed the package to validate. The test ruled out content library issues, and proved the theory around character limits.

-Tony