MSEndpointMgr

DownloadFileWithRanges() failed 80072ee2 on Packages in ConfigMgr 2012 R2

Lately there’s been reports about random files in Packages is causing a Task Sequence to fail. I’ve as well seen this on one of my customers running ConfigMgr 2012 R2 (no CU1). The error that is shown in smsts.log is the following:

WinHttpSendRequest failed.
SendWinHttpRequest failed. 80072ee2.
DownloadFileWithRanges() failed. 80072ee2.

and then some rows further down:

DownloadFiles() failed. 80072ee2.
Download() failed. 80072ee2.

Over at the TechNet forums, this has been reported to happen for the Use Toolkit Package (MDT Toolkit package), see this thread. There’s seems to be some thoughts regarding why this issue is occurring, where it’s believed that it has something to do with the disk drive performance of the system that is being deployed, especially if the system is equipped with a SSD drive. I’ve only experienced this issue on virtual machines (VMWare) with low disk drive performance (SATA). Perhaps the SAN cache controller has something to do with this, but at this point that’s just a theory.
Microsoft is aware of this issue and are currently working for a fix. But for the time being, we’ll have to apply a work around. I’ll keep this post updated as I found out more about regarding this issue.

Work around

If you’re experiencing this issue, you can apply the following working.
1. Open the Task Sequence used for your deployments.
2. At the very top underneath Install Operating System, add a Set Task Sequence Variable step. Configure it accordingly:
Name: Set SMSTSDownloadRetryCount
Task Sequence Variable: SMSTSDownloadRetryCount
Value: 5
102_1
3. Below the Set SMSTSDownloadRetryCount step, create a new Set Task Sequence Variable step, and configure it accordingly:
Name: Set SMSTSDownloadRetryDelay
Task Sequence Variable: SMSTSDownloadRetryDelay
Value: 15
102_2
With these two variables set, the issue should be resolved. If you’re using an MDT integrated Task Sequence, you could add these to your CustomSettings.ini, but don’t forget to add them as custom Properties.

Nickolaj Andersen

Chief Technical Architect and Enterprise Mobility MVP since 2016. Nickolaj has been in the IT industry for the past 10 years specializing in Enterprise Mobility and Security, Windows devices and deployments including automation. Awarded as PowerShell Hero in 2015 by the community for his script and tools contributions. Creator of ConfigMgr Prerequisites Tool, ConfigMgr OSD FrontEnd, ConfigMgr WebService to name a few. Frequent speaker at conferences such as Microsoft Ignite, NIC Conference and IT/Dev Connections including nordic user groups.

18 comments

  • Hey Nickolaj,
    I’ve found that if you compress the driver package into a .zip file, the client running the task sequence downloads the content not only without error, but it completes the download many, many times faster. You can then extract the archive with powershell once the content is downloaded and proceed as normal.
    Is this something you could possibly look into implementing in your driver automation tool/modern driver management script?

  • genius man…I realize this is an old post but saved me from literally ripping all my hair out.

  • Interestingly this seemed to help, somewhat in our environment, but after nearly a month a can say it doesn’t entirely solve it.

    • Interesting notes there Bill. For all the customers I’ve implemented this, it has worked flawlessly. What are the circumstances when it doesn’t work?
      Regards,
      Nickolaj

  • Thank you so much for posting this. I just finished making these changes in our environment a few hours ago and now all is working correctly. Much appreciation!

  • I can’t stress enough that if you have this problem call premier support and log the issue. This helps push the priority to get the problem fixed, and gives Microsoft more information from more sources to work the issue. Since this is a bug, you will not be charged for the incident.

  • The Premier support engineer assigned to the case I have open on this problem (but never found the bug that seems to involved here in the last few months…go figure!) indicates based on the information that the problem (he found the bug report now) is related to the use of “OSDPreserveDriveLetter” = “True”

    • Thanks Bill for sharing your interactions and findings with MS. I hope that this will be solved in CU3 or with some other hotfix.
      Regards,
      Nickolaj

  • BTW we found that setting our Lenovo machines (99% of our machine population) to “Legacy BIOS” as opposed to “Both” seemed to help with, but not entirely eliminate the problem.

  • Add: Run Command Line
    Name: Sleep 60 Sec
    Command line: Powershell.exe –command Start-Sleep 60
    This fix my problem by install Applications/Image on SSD driver

Sponsors

Categories

MSEndpointMgr.com use cookies to ensure that we give you the best experience on our website.