Hi Environment is SCCM 2007 with R3. I have seen others with the same issue but their fixes doesn't' do it for me. I have "Setup windows and configmr" that installs the client agent in my task sequence. Everything is fine up till then. On the win7 desitation, system does a pxe boot, paritions are created, system is added to the domain but when it gets to the client agent install piece of it here is what happens 1-some kbXXXX.exe files are downloaded to the pxe client from sccm http 2-I get the error code (0x80081007) and it gives me 15 minutes to reboot. ------------------- I have updated my x64 & x86 base boot wims. I have also updated and refreshed the os packages. I also went and deleted my base wims and packages and recreated them. Nothing works. When I look at smsts.log on the client, I see this entry near the bottom: 1. Hash could not be matched for the downloded content. 2. "Failed to run the last action: Setup windows and configmgr. Execution of task sequence failed. The hash value is not correct" Would you please help? Thank you

This is an "infamous" ConfigMgr issue. Basically, the hash generated by the client for the content you are downloading does not match the hash generated for the content on the site server and so the client is rejecting the content. Hashes are used to make sure the content hasn't been corrupted or tampered with in transit or once stored. This is unfortunately a common issue in ConfigMgrFor some known reasons and some other unknown reasons. Larger files (like WIMs) seem particularily affected by this issue. The typically path to resolving this issue is to first update the content on the DP with the hash mismatch issue and try again. If that doesn't work, you'll have to recreate the package.Jason | http://blog.configmgrftw.com | Twitter @JasonSandys

I have done both to no avail :-(

Have you exlcuded the content from A/V scanning? Have you verified that there are no special characters in the any of the file or folder names (this is known to throw off the hash algorithm)? Have you verified that you are working with the correct package that is getting the issue?Jason | http://blog.configmgrftw.com | Twitter @JasonSandys

I did all that. Eventually I had to go to advertisement's property and set it to access it from desntiation point!!!!!!. Thank you so much

I did all that. Eventually I had to go to advertisement's property and set it to access it from desntiation point!!!!!!. Thank you so much If I recall correctly, the hash is not checked when running software from a DP. If you're having problems with the ConfigMgr client install, perhaps you should update the distribution points on that package. If that doesn't help, delete and recreate the package.Nicholas Jones, MCITP | Core Infrastructure Consultant | Sparkhound | https://www.mcpvirtualbusinesscard.com/VBCServer/nicholas.jones/profile

One common situation that I have seen is that users browse through the folders on the DP using Windows Explorer. Unfortunately, Windows Explorer automatically creates all sorts of hidden files on the folders that one is browsing through. This pollutes the package on the DP. Those hidden files get downloaded by the client and so the total hash of the package on the client never matches the one that was computed on the site. As others have suggested, creating a new package has the best change of getting rid of the hash mismatch.

Hey Kman2k, Are you applying any MSPs with the "PATCH=xxxxxx" switch in the ConfigMgr install? If so, maybe try removing them and just doing a base client install. Cheers, Mark

I ran into this problem today actually. In the properties of the advertisement I selected Distribution Points and selected the radio for "Access content directly from a distribution point when needed by the running task sequence". This did work for me, however it does mess with deploying FEP 2010 because in order to run FEP2010 during a task sequence is to "Download content locally when needed by running task sequence". Hope that helps.

Thank you all for your help. I did all the refreshing, recreating and updating of distribution points to no avail :-(. There are no hidden files and I made sure of that as well. I also tried installing the client agent without the patch parameter as suggested by Mark. The only solution for me was to go to properties of the advertisement and check the box for "Access content directly from a distribution point when needed.......".

I came accross this, maybe it well help. My issue started today when I loaded new drivers into SCCM. http://0wned.it/geek-bits/scripts/finding-bad-files-that-upset-configmgr-hash-could-not-be-matched-for-the-downloaded-content/

I still suggest you checking if the package contains files with names containing extended ASCII characters. See ConfigMgr 2007: SMSTS error "Hash could not be matched for the downloaded content" If this is the case, it is a known issue. And the workaround is renaming all files to names without extended characters or specifying that the task sequence advertisement Download all content locally before starting the task sequence in Advertisement Properties - Distribution Points Tab.Sabrina TechNet Community Support

I still suggest you checking if the package contains files with names containing extended ASCII characters. See ConfigMgr 2007: SMSTS error "Hash could not be matched for the downloaded content" If this is the case, it is a known issue. And the workaround is renaming all files to names without extended characters or specifying that the task sequence advertisement Download all content locally before starting the task sequence in Advertisement Properties - Distribution Points Tab. Sabrina TechNet Community Support Hi Sabrina, Thanks for you adivce, very helpful.