Today I was noticing on a few of our advertisements that all of our machines in the collection had received the "Program failed (download failed - content mismatch)" failure message. Upon receiving this error message, I came across a blog post by Matthew Boyd that referred to the following:
Binary Differential Replication – If this is enabled in the package configuration, some packages seem to fail. I’m assuming that they can’t handle this kind of replication and several of the files become corrupt, creating a hash mismatch. This can be turned off by opening up the package properties, going to the Data Source tab, and unchecking Enable binary differential replication. This wasn’t my problem because I hadn’t enabled binary differential replication.
Hidden Files – Apparently, if the package source contains hidden files, SCCM may not calculate the correct hash for the package and clients could encounter an error. I found a quick way to check this using the command line:
- Open up a command window in the root director that contains your package source files.
- Type Dir /S /A:H and hit enter. Depending on the package, you may be presented with several directories with multiple hidden files.
- Trying to remove the hidden attribute on all the files with the GUI would be tedious, so just use this command instead: attrib -H /S
- Update Distribution Points
For my environment, BDR has never been an issue with content mismatches. So for the specific package I was working on I looked at my package source and sure enough there were some hidden files in the source.
So my next step was to look at my entire package source folder and I noticed that there were a lot of packages that had some hidden files. I went through their advertisement reports and sure enough, these packages also had content mismatch failures.
Thanks to Matthew for posting the tip.
Related External Links
- Generated by LinkCurl