The 1610 update for SCCM had been stuck in the downloading state, with a last update time of three days ago. There’s a note within the SCCM console that if an update is stuck in the downloading state for a long period of time you should restart the SMS_EXECUTIVE (smsexec) service on the standalone primary or central administration site server (CAS).
I restarted this service, but nothing changed. The next step was to check dmpdownloader.log, which can be found in C:\Program Files\Microsoft Configuration Manager\Logs. This contained the error below, where I’ve replaced the proxy and SCCM server name with placeholders.
ERROR: Failed to download redist for 91406b1d-7c14-42d8-a68b-484be5c5e9b8 with command /RedistUrl http://go.microsoft.com/fwlink/?LinkID=831290 /LnManifestUrl http://go.microsoft.com/fwlink/?LinkID=831291 /RedistVersion 112015 /ProxyUri http://%PROXYURL%/ /NoUI “\\%SCCMSERVERNAME%\EasySetupPayload\91406b1d-7c14-42d8-a68b-484be5c5e9b8\redist” .
Looking in the C:\Program Files\Microsoft Configuration Manager\EasySetupPayload\91406b1d-7c14-42d8-a68b-484be5c5e9b8\redist folder, I could see the last modified date was three days ago, equal to the last update time in the console. I was able to manually download the two CAB files in the above error, so there wasn’t an access issue. I restarted the SMS_EXECUTIVE (smsexec) service again and this time I could see some more files had been download to the redist folder. Unfortunately, the update was still listed as downloading. I restarted the SMS_EXECUTIVE (smsexec) service again, which again resulted in some more files appearing in the redist folder and the update became available. So the take away from this is that if the update is stuck in a downloading state you may have to restart the SMS_EXECUTIVE (smsexec) service more than once.