Solution: ConfigMgr 2007 clients may fail to download packages from a Server Share DP with a content hash mismatch error

Solution: ConfigMgr 2007 clients may fail to download packages from a Server Share DP with a content hash mismatch error

  • Comments 1
  • Likes

image Here's a ConfigMgr 2007 issue I had recently that was caused by an known issue with IIS.  I wanted to publicize this here so that it might help others who run into this problem.

Issue:

Configuration Manager 2007 clients may fail to download packages from a Server Share Distribution Point with a content hash mismatch error if using BITS/HTTP.  You may see the following errors in the cas.log and contenttransfermanager.log:

CAS.Log:
Download completed for content PackageGUID.X under context System 3/25/2010 12:31:21 AM 2096 (0x0830)
Failed to instantiate UI Server {SOMEGUID1} with error 8000401a 3/25/2010 12:31:21 AM 2096 (0x0830)
Failed to instantiate UI Server 2 {SOMEGUID2} with error 8000401a 3/25/2010 12:31:21 AM 2096 (0x0830)
Failed to instantiate Updates UI Server {SOMEGUID3} with error 8000401a 3/25/2010 12:31:21 AM 2096 (0x0830)
Failed to instantiate VApp UI Server {SOMEGUID4} with error 0x8000401A 3/25/2010 12:31:21 AM 2096 (0x0830)
There are 0 files in the directory compared to 1 expected files 3/25/2010 12:31:21 AM 2096 (0x0830)
Hash does not match expected <Content ContentId="PackageGUID" Version="X"><FileContent Name="Package Name" Hash="SomeHashValuenumber" HashAlgorithm="SHA1" Size="513400"/></Content>, actual  3/25/2010 12:31:21 AM 2096 (0x0830)
Hash matching failed. 3/25/2010 12:31:21 AM 2096 (0x0830)
Download failed for content PackageGUID.X under context System, error 0x80091007 3/25/2010 12:31:21 AM 2096 (0x0830)

So it thinks it downloaded, but it really did not, and the clients cache is not populated with the package ID named folder so this explains why the hash mismatch occurs.

ContentTransferManager.log:
CTM job {SOMEGUID} successfully processed download completion. 3/25/2010 12:31:34 AM 3500 (0x0DAC)
CTM encountered error processing reply from DTS. Code 0x80040215 3/25/2010 12:33:06 AM 3084 (0x0C0C)

So it actually showed a download complete, then it gave the error above.

Cause:

There is a known issue with IIS 6.0 WEBDAV that occurs when the Virtual Directory points to the root of the drive as the path, such as Z:\.  This causes our failure above.

Resolution:

The workaround is to create a folder on the drive and share that to create the DP Server share instead. 

In this case there were already many servers configured by sharing out the Z:\ drive and configured for use as a Remote Server Share DP in Configuration Manager 2007. Also, all the packages were already replicated to the Z:\SMSPKG folder on those remote servers, so all the packages multiplied by the number of servers added up to a lot of man-hours.  It was going to take a long time to recreate this from scratch and redistribute all the packages again.

Instead of recreating everything, we devised a workaround that would still involve moving the SMSPKG folder from the root of Z:\ to a newly created folder Z:\packages and then deleting and recreating the packages share on the remote server so that the Z:\packages folder is shared as packages instead of the root of the Z:\ drive.  We would then modify the path on the SMS_DP_packages virtual directory so that it points to the Z:\packages folder instead of the root of the Z:\, which was the configuration that was not working. So having to do this on 99 servers was still a challenge, but by our estimates would be less work than starting over from scratch, and it worked as expected.

So this allows the ConfigMgr 2007 settings to remain the same, as the actual share path that the packages are deployed to from the Primary site server remains the same (\\servername\packages\SMSPKG) and this resolves/works around the IIS 6 issue by changing the virtual directory properties to point to a folder on the drive rather than the root of the drive.

We tested this with the copying of one package to the new Z:\packages folder and sharing it as packages instead of the root of the Z:\ drive on one remote DP, and modifying the virtual directory to point to the Z:\packages folder.  After doing this the client was able to successfully download the package using HTTP and it executed successfully without a hash mismatch error.

Additional Information and Resources:


I found some documentation that indicates you should use a folder rather than the root of a drive as Server Share DP this on this site:

http://technet.microsoft.com/en-us/library/bb892801.aspx

It says:

"Administrator must manually create a shared folder before creating the new site system server share."

It mentions create a shared folder, not a shared drive, so it would seem this is documented, but it does not point out that if you use the root of a drive it will break BITS/HTTP transfers.

More Information

See KB954847 - IIS 6.0 returns path information that is incorrect when you use the WebDAV PROPFIND method:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;954847

Clifton Hughes | Senior System Center Support Engineer

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Would this apply if SCCM 2007 is installed on Server 2008 r2?  It seems like it is using IIS 7.