Step 2: Reproduction of the Scenario

In our scenario, we had an available software update group deployment where Google Chrome 81.0.4044.113 (x64) UpdateID: ff665b30-ccef-4806-9f81-7b5a762063d5 was targeted to a device using CMG on the internet.

Since this was an available deployment, we started the update installation using software center, but a required deployment would have the same download errors.

Once the download is triggered, we will see the following data in DataTransferService.log

CDTSJob::HandleErrors: DTS Job ‘{857B9A7B-0908-44AE-BB80-96F30EF11E96}’ BITS Job ‘{0B57534F-36B3-4BA9-A07E-850F1B5C0CE4}’ under user ‘S-1-5-18’ OldErrorCount 0 NewErrorCount 1 ErrorCode 0x80072EE7

Failed to set proxy to bits job for url ‘http://sccm:80/Content/EB/2ABF1D5BCD7564FD2DF0E8DC6CFB628E6DEA4FEB.cab’. Error 0x87d00215

All proxy types and no proxy have been tried but failed. Loop the types again for the 1 time

The first interesting thing we notice is the client attempts to download the content from the internal WSUS server, but this actually isn’t our issue and is a known scenario please see our UserVoice request to improve this behavior. The download against the internal WSUS will usually timeout after 3 attempts and fall back to your CMG-based distribution point.

The log that will help us see the issues in this scenario is DeltaDownload.log. In this log, we can see the following lines:

Failed to send HTTP Response. Error=800704cd

We will see this happen for each update every 3 minutes for about 30 minutes before the download will fail.

Once the download times out, we will see the following error in WUAHandler.log.

Unexpected HRESULT for downloading complete: 0x80d02002