ConfigMgr 2007 Clients fail to download packages from a Server Share Distribution Point with a content hash mismatch error if using BITS/HTTP

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.