Was onsite with a customer recently, and had failure trying to upgrade their Build 1610 Current Branch Hierarchy to Build 1702.


The problem was being reported in the SMS_DMP_Downloader log as follows:



If you follow the links you’ll end up downloading CAB files, these are not the files that the downloader is having trouble with, there is further details being logged in the ConfigMgrSetup log, which will indicates the file or files the downloader is failing to download or hash verify.


The CAB files referenced in SMS_DMP_DOWNLOADER contain the metadata for all the files that need to be downloaded for setup to commence, which includes the filename, file size, and a hash so that the files can be hash verified once downloaded, and once verified they are stored away in readiness for use during the upgrade, or discarded and an error thrown.


So if you are experiencing failure in this area, you are either experiencing a denial to download most likely caused by Proxy settings, noting that SMS_DMP_DOWNLOADER is running in SYSTEM context and not USER context, or you are experiencing a hash verification issue due to a corrupted download or simply failure to hash. There could be other variants I’ve not listed, but to date this is all I’ve seen.


Fixing a Proxy settings is a cinch, and if that is your problem then you should be able to fix it up quickly and skip over the rest of this post, and get your upgrade underway.


The release notes for Current Branch detail this issue, and provide a workaround: https://docs.microsoft.com/en-us/sccm/core/servers/deploy/install/release-notes




The suggested workaround is to tweak the Software Publishing registry value which resides in the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers registry path.


This value corresponds to the Internet Explorer security setting Check for publisher’s certificate Revocation and Check for signatures on downloaded programs, as noted here, with a bit of a deep dive here.


I know that SMS_DMP_DOWNLOADER is running under SYSTEM context, and not the currently logged in USER, so I am unsure as to why the Registry Hive is HKCU, and not HKLM, but this is offered as a workaround and I see others have reported it helping them.


Another fix is to get the binaries being referred too in the ConfigMgrSetup log, download them yourself, or obtain from another Hierarchy that went from your build to the build you are upgrading too, and pop them into the location that the downloader is trying to store them in. Rerun the Site upgrade, and repeat if necessary until the upgrade is underway, resorting to the registry change if the hashing is failing completely. This helped me get the upgrade underway.