ConfigMgr 2007: SMSTS error "Hash could not be matched for the downloaded content"

ConfigMgr 2007: SMSTS error "Hash could not be matched for the downloaded content"

  • Comments 2
  • Likes

Here's an issue I hadn't seen before that was sent to me by Clifton Hughes, one of our top System Center Configuration Manager 2007 engineers at our Las Colinas site in Irving, Texas.  If you do any work with packages that contain localized file names then you'll want to be aware of this:

========

Issue: When deploying a software package in SCCM 2007 via a Task Sequence, and that package contains files with names containing extended ASCII characters, the Task Sequence may fail with an error code 80004005.  An example would be something like the Spanish word año where there's a tilde over the 'n.'

The following is an example excerpt from my SMSTS.LOG for a file name that includes extended ASCII characters:
Downloaded file from _http://smtp.contoso.com:80/SMS_DP_SMSPKGD$/CON00016/Speedup/Translations/Espa%C3%B1ol.txt to C:\_SMSTaskSequence\Packages\CON00016\Speedup/Translations/Español.txt

Note how the file is being renamed to Español.txt instead of the proper name espanol.txt with the tilde above the a.

The Task Sequence will fail with an Unspecified error 80004005 and the following error will also appear in the SMSTS.LOG:

Task sequence execution failed with error code 80004005

Cause:  These types of extended characters in the file names are not downloaded/named correctly and the file names will get created differently than the original files names, causing the hash mismatch error. This is a known issue in SCCM2007 and an update will be provided once it becomes available.

Resolution: For now, the workaround is to remove any files that have extended characters in their names from the package source and redistribute the package with out these files.

This problem can and will occur with a standalone Software Package if it is deployed using a Task Sequence, of if you are deploying the package as part of an Operating System Deployment via a Task Sequence. It does not seem to affect normal Software Package deployment as long as a Task Sequence is not used.

========

Thanks Clifton!

J.C. Hornbeck | Manageability Knowledge Engineer

Comments
  • Hello guys perhaps somebody have seen this behaviour and knows the fix.

    I created a task sequence using the install existing image package option.

    I created a migdata.xml and added this to the list of custom configuration files to both the capture and load parts of usmt.

    I tried a run and it automatically created an assocation "in-place" so that is can do a reinstall preserving the data folder on the c-drive. This works all fine.

    The only question is that when the task sequence is finished the machine is not a member of the domain although I have set it to add it to the domain and specified an account with domain admin permissions.

    I tried this task sequence with and without the capture network settings but this had no effect.

    Please tell me what I do wrong.

    Arjan

  • LA_1976, it does not seem related to this blog post, however your issue could be caused by any number of problems, I would recommend checking the client logs (SMSTS.LOG, and SETUPACT.LOG) these may prove useful in finding clues as to the failure with the domain join step of the Task Sequence. Hope this helps.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment