Nickolaj AndersenLately 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
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
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.
Mattias Melkersen
Rudy Ooms
Ben Whitmore
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?
Hi Stephen, I’ll talk to Maurice about it. It could be an option in DAT where there’s a check box to zip all of the contents if desired.
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!
Hi Douglas,
Sorry for the late reply. I’m glad that I was able to help!
Regards,
Nickolaj
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.
CU1 and CU2 are affected by this.
Excellent, thank you!
You’re welcome!
Regards,
Nickolaj
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
Hi Maarten,
Interesting work around, thanks for sharing! 🙂
Regards,
Nickolaj
where in TS do you put this?
Hi Patrik,
I suggest that you read through the post, where you have a detailed description of how to implement it.
Regards,
Nickolaj