ConfigMgr 2007 Clients 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.
Symptoms
Known bug in IIS 6.0 WEBDAV where the Virtual Directory points to the root of the drive as the path, such as Z:\.
Cause
The workaround is to create a folder on the drive and share that to create the DP Server share on instead.
In this case, there were already 99 servers configured by sharing out the Z:\ drive and configured for use as 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... was going to take a long time to recreate from scratch and re distribute all the packages again. This have taken weeks in this environment while they updated all these remote DP's again.
We devised the following 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, 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 of a hassle 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 bug, 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 shared it as packages instead of the root of the Z:\ drive on one remote DP, and modified the virtual directory to point to the Z:\packages folder, and the client was able to successfully download the package using HTTP, and it executed successfully with out a hash mismatch error.
ADDITIONAL INFORMATION AND RECOMMENDATIONS:
I found some documentation, that at least implies 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
Server Share - Disadvantage - 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, however vague it may be, and it also does not point out that if you use the root a drive, it will break BITS/Http transfers, and allows SMB connections to succeed.
Resolution
954847 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
