Why do hash mismatches occur in ConfigMgr? If I could authoritatively answer that question then I could probably fix the issue and answer countless posts in the forums and mailing lists – most of which seem to have different fixes or causes. There are a handful of very good blog posts on troubleshooting and resolving this issue though including this one on Organic Fertilizer, SCCM: Content hash Fails to Match, and this one titled ConfigMgr (SCCM) Hash Mismatch Issue.
Even with a couple of hotfixes and all that is known about hash mismatches, it still seems to crop up and plague every ConfigMgr 2007 hierarchy – that is except those using a true Alternate Content Provider like Adaptiva’s OneSite.
OneSite completely replaces the content distribution model in ConfigMgr which is at the heart of the issue and thus side steps the issue completely. OneSite does in fact use its own secure hash algorithm to verify content so that it cannot be tampered with or corrupted in transit or once delivered; however, OneSite’s algorithm and process for calculating the content’s hash value has never exhibited any of the seemingly random issues that crop up in ConfigMgr’s native content distribution process and hash generation. OneSite directly acquires content from the site server (the package source directory actually) and then securely distributes the content to the targeted clients as needed.
In our many customer production and lab environments and our own lab environments, we have never had a single case of this issue. No muss, no fuss, no mismatch.