Hi All, We are trying to deploy a large (30Gb) windows 7 wim image to rooms of PCs and are having many (up to half) of the clients fail with a Hash Mismatch for the wim image package. The error occurs during the apply operating system step of the task sequence, after download and extraction of the image. We are using an autocast multicast to rooms of about 16 PCs and have had varying results, some clients successfully build and others don't. It happens both at our central site and child primary sites. It doesn't seem to be related to the PC models as 3 different models have been imaged, all with some successful and some failures. It can't be a problem with the image package on the DPs because there are successful deployments from the same image and task sequnce. Our environment is as follows: 1 Central Site server (MP, DP, PSP, Multicast enabled) running Windows 2008 R2, SCCM R2 SP2 on VMWare ESX 3.5 Child Primary servers (MP, DP, PSP, Multicast enabled) also Windows 2008 R2, SCCM R2 SP2 on VMWare ESX 3.5 Multicast is set to use range 239.0.1.1-255 (set in registry and via gui), set to Autocast. If we go back to our old deployment tool we can get 100% success (admittedly a smaller xp image). We are now having a hard time trying to justify the decision to use SCCM when it seems unreliable in comparison. I'm at a loss to explain why there is such a high failure rate or to come up with a reliable solution. I would most appreciate any advice as to what to try next.

Hello - You can use HashDir tool to findout the HASH value. I think, you can also try to Refresh DPs Also, Try the points mentioned in the below blog. http://brothertu.blogspot.com/2008/09/error-hash-value-is-not-correct-when.htmlAnoop C Nair

I have an update and a possible solution. I found this post in the WDS forums, which suggests reducing the multicast block size (ApBlockSize) to improve performance. http://social.technet.microsoft.com/Forums/en-US/winserversetup/thread/8e4c2df0-23ed-4ab9-811e-f2011b5b822d Well I did reduce the block size and so far (fingers crossed) the success rate has been 100%. So it appears that sending large packets which subsequently are fragmented can increase the chances that the image download fails if the network is not 100% reliable. The only trade-off is that it takes longer to image. Many thanks to the OP of that thread and Aaron Tyler for putting me on the right track.