I'm running SCCM 2012 R2 RTM with separate site server and distribution point servers, both running Server 2012 R2 fully patched.
A bunch of my clients are unable to download a brand new application version I deployed. They pull from different distribution points (on which the packages verify fine). Each of them is getting a "failed to do hash verification" error and they all compute the same exact incorrect hash. Last week we tested this application with a small group of users and they all installed it successfully. The failing clients get the following in CAS.log:
Download started for content Content_fcd2b225-ec3e-4377-a735-90b4c9ea52a9.1 ContentAccess 4/12/2016 11:17:22 AM 12100 (0x2F44)
Download completed for content Content_fcd2b225-ec3e-4377-a735-90b4c9ea52a9.1 under context ContentAccess 4/12/2016 11:17:49 AM 13096 (0x3328)
Computed hash: 1CA08CB5E518DBDCE8353520F1655CBCA6D16D5427C9E28D257FE8EF7E64295A ContentAccess 4/12/2016 11:17:49 AM 13096 (0x3328)
Failed to do hash verification with preference : 4. Try to verify at next hash algorithm ContentAccess 4/12/2016 11:17:49 AM 13096 (0x3328)
Download failed for content Content_fcd2b225-ec3e-4377-a735-90b4c9ea52a9.1 under context , error 0x80091007 ContentAccess 4/12/2016 11:17:49 AM 13096 (0x3328)
Download failed for download request {328C3260-10D4-4AC2-AF76-72A91E96068E} ContentAccess 4/12/2016 11:17:49 AM 13096 (0x3328)
Successfully raised SoftDistHashMismatchEvent event. ContentAccess 4/12/2016 11:17:49 AM 13096 (0x3328)
Error: DeleteDirectory:- Failed to delete Directory C:\WINDOWS\ccmcache\23.BCWork with Error 0x00000002.
When I and a few others run it we get this:
Download completed for content Content_fcd2b225-ec3e-4377-a735-90b4c9ea52a9.1 under context ContentAccess 4/12/2016 3:42:09 PM 39760 (0x9B50)
Computed hash: F3B4AB75DBEE531A6D1021F80D41BB81F508A755683770CB108FBF894AC26B77 ContentAccess 4/12/2016 3:42:09 PM 39760 (0x9B50)
Hash verification succeeded for content Content_fcd2b225-ec3e-4377-a735-90b4c9ea52a9.1 downloaded under context ContentAccess 4/12/2016 3:42:09 PM 39760 (0x9B50)
Saved Content ID Mapping Content_fcd2b225-ec3e-4377-a735-90b4c9ea52a9.1, C:\WINDOWS\ccmcache\9b ContentAccess 4/12/2016 3:42:09 PM 39760 (0x9B50)
I've tried:
* Recreating the application from scratch twice
* Pointing the newly-created application to a new source directory with an text file inside to ensure a new hash (almost worked, see below)
* Disabling anti-virus to ensure it's messing with ccmcache (We already have an exception set for ccmcache so this was just in case)
* Pointing users to an alternate distribution point
* Removing the supersedence relationship
I haven't tried:
* Rebooting the distribution point (can't do it until at least the weekend)
The weirdest part of the whole thing is that after pointing the newly-created application to a new source directory I had one of my testers try it and it downloaded but didn't install properly. I realized that my developer forgot to increment the MSI
version number so msiexec thought it was already installed and closed but it SCCM didn't detect it on the machine (different detection method). I manually incremented the version on the MSI in the source directory, updated content, had him try again,
and it worked perfectly. Once I asked a few more people to test they got the same hash verification failures as they did with the last application.
How is it that multiple clients can calculate the same incorrect hash and fail to do hash verification and what can I do to fix it? How does the client know what hash to compare against and where does it come from?