Hi there,

I have a SCCM 2012 R2 environment running on Windows Server 2012 on VMWare Workstation 10.0.1. My TS is deploying Win7x64 to another VM. I am using MDT integration and the first action after "Setup Winodws and ConfigMgr", and restarting from WinPE to Win7, is "Use Microsoft Deployment Toolkit Package". It always downloads part of the package before it fails on a seemingly random file.

From the F8 prompt i am able to ping the MP/DP. From the MP/DP I am also able to download the file in question using Internet Explorer. From my viewpoint this looks like a transient network error, but I am open to any suggestions at this point. I have also seen the TS run through without a hitch once, so it seems like it's not perfectly consistent.

Does anyone have any idea as to what could cause this? Where should I be looking? Any troubleshooting tips?

External link to smsts.log

Snippet of my TS

Snippet from the smsts.log:

Downloading file /SMS_DP_SMSPKG$/CEN00024/sccm?/Scripts/DeployWiz_Computer.png range 0-6593	InstallSoftware	2014-02-04 12:43:24	2356 (0x0934)
Downloaded file from http://CM01.spectre.local:80/SMS_DP_SMSPKG$/CEN00024/sccm?/Scripts/DeployWiz_Computer.png to C:\_SMSTaskSequence\Packages\CEN00024\Scripts/DeployWiz_Computer.png 	InstallSoftware	2014-02-04 12:43:24	2356 (0x0934)
Downloading file /SMS_DP_SMSPKG$/CEN00024/sccm?/Scripts/DeployWiz_ComputerBackup.vbs range 0-2690	InstallSoftware	2014-02-04 12:43:24	2356 (0x0934)
Downloaded file from http://CM01.spectre.local:80/SMS_DP_SMSPKG$/CEN00024/sccm?/Scripts/DeployWiz_ComputerBackup.vbs to C:\_SMSTaskSequence\Packages\CEN00024\Scripts/DeployWiz_ComputerBackup.vbs 	InstallSoftware	2014-02-04 12:43:24	2356 (0x0934)
Downloading file /SMS_DP_SMSPKG$/CEN00024/sccm?/Scripts/DeployWiz_ComputerBackup.xml range 0-2999	InstallSoftware	2014-02-04 12:43:24	2356 (0x0934)
Downloaded file from http://CM01.spectre.local:80/SMS_DP_SMSPKG$/CEN00024/sccm?/Scripts/DeployWiz_ComputerBackup.xml to C:\_SMSTaskSequence\Packages\CEN00024\Scripts/DeployWiz_ComputerBackup.xml 	InstallSoftware	2014-02-04 12:43:24	2356 (0x0934)
WinHttpSendRequest (hRequest, pszAdditionalHeader != NULL ? pszAdditionalHeader : WINHTTP_NO_ADDITIONAL_HEADERS, (DWORD)-1, NULL, 0, 0, NULL), HRESULT=80072ee2 (e:\qfe\nts\sms\framework\tscore\downloadcontent.cpp,1211)	InstallSoftware	2014-02-04 12:43:45	2356 (0x0934)
WinHttpSendRequest failed.	InstallSoftware	2014-02-04 12:43:45	2356 (0x0934)
SendWinHttpRequest failed. 80072ee2.	InstallSoftware	2014-02-04 12:43:45	2356 (0x0934)
SendWinHttpRequest (hSession, hConnect, hRequest, pszSourcePath, sWinHttpRangeHeader.c_str(), bUseSSL, ullContentLength, LastGoodCredentialsType), HRESULT=80072ee2 (e:\qfe\nts\sms\framework\tscore\downloadcontent.cpp,1424)	InstallSoftware	2014-02-04 12:43:45	2356 (0x0934)
DownloadFileWithRanges() failed. 80072ee2.	InstallSoftware	2014-02-04 12:43:45	2356 (0x0934)
DownloadFileWithRanges (hSession, hConnect, sRequest, hFile, pszDestination, ullFileSize, ulPackageSize, ulDownLoaded, LastGoodCredentialsType, bUseSSL), HRESULT=80072ee2 (e:\qfe\nts\sms\framework\tscore\downloadcontent.cpp,1514)	InstallSoftware	2014-02-04 12:43:45	2356 (0x0934)
DownloadFile() failed for http://CM01.spectre.local:80/SMS_DP_SMSPKG$/CEN00024/sccm?/Scripts/DeployWiz_ComputerName.vbs, C:\_SMSTaskSequence\Packages\CEN00024\Scripts/DeployWiz_ComputerName.vbs. 80072ee2.	InstallSoftware	2014-02-04 12:43:45	2356 (0x0934)
DownloadFile (hSession, hConnect, sSourceFile.c_str(), sDestinationFile.c_str(), ulPackageSize, ulDownLoaded, LastGoodCredentialsType, bUseSSL), HRESULT=80072ee2 (e:\qfe\nts\sms\framework\tscore\downloadcontent.cpp,1590)	InstallSoftware	2014-02-04 12:43:45	2356 (0x0934)
Error downloading file from http://CM01.spectre.local:80/SMS_DP_SMSPKG$/CEN00024/sccm?/Scripts/DeployWiz_ComputerName.vbs to C:\_SMSTaskSequence\Packages\CEN00024\Scripts/DeployWiz_ComputerName.vbs 	InstallSoftware	2014-02-04 12:43:45	2356 (0x0934)
DownloadFiles() failed. 80072ee2.	InstallSoftware	2014-02-04 12:43:45	2356 (0x0934)
DownloadFiles (setDirs, setFiles, sDestination.c_str(), bUseSSL), HRESULT=80072ee2 (e:\qfe\nts\sms\framework\tscore\resolvesource.cpp,2529)	InstallSoftware	2014-02-04 12:43:45	2356 (0x0934)
Download() failed. 80072ee2.	InstallSoftware	2014-02-04 12:43:45	2356 (0x0934)
DownloadContentAndVerifyHash() failed. 80070002.	InstallSoftware	2014-02-04 12:43:45	2356 (0x0934)
DownloadContentAndVerifyHash ( pszPackageID, L"SMSPackage", saHttpContentSources, saSMBContentSources, saMulticastContentSources, sDestination, dwFlags, L"", 0, dwPackageFlags, mapNetworkAccess ), HRESULT=80070002 (e:\qfe\nts\sms\framework\tscore\resolvesource.cpp,3052)	InstallSoftware	2014-02-04 12:43:45	2356 (0x0934)
DownloadContentLocally (pszSource, sSourceDirectory, dwFlags, hUserToken, mapNetworkAccess), HRESULT=80070002 (e:\qfe\nts\sms\framework\tscore\resolvesource.cpp,3273)	InstallSoftware	2014-02-04 12:43:45	2356 (0x0934)
TS::Utility::ResolveSource (pszPkgID, sPath, 0, hUserToken, mapNetworkAccess), HRESULT=80070002 (e:\nts_sccm_release\sms\client\osdeployment\installsoftware\runcommandline.cpp,399)	InstallSoftware	2014-02-04 12:43:45	2356 (0x0934)
Failed to resolve the source for SMS PKGID=CEN00024, hr=0x80070002	InstallSoftware	2014-02-04 12:43:45	2356 (0x0934)
cmd.Execute(pszPkgID, sProgramName, dwCmdLineExitCode), HRESULT=80070002 (e:\nts_sccm_release\sms\client\osdeployment\installsoftware\main.cpp,372)	InstallSoftware	2014-02-04 12:43:45	2356 (0x0934)
Install Software failed to run command line, hr=0x80070002	InstallSoftware	2014-02-04 12:43:45	2356 (0x0934)
Process completed with exit code 2147942402	TSManager	2014-02-04 12:43:45	1672 (0x0688)
!--------------------------------------------------------------------------------------------!	TSManager	2014-02-04 12:43:45	1672 (0x0688)
Failed to run the action: Use Toolkit Package. 
The system cannot find the file specified. (Error: 80070002; Source: Windows)	TSManager	2014-02-04 12:43:45	1672 (0x0688)
MP server http://CM01.spectre.local. Ports 80,443. CRL=false.	TSManager	2014-02-04 12:43:45	1672 (0x0688)
Setting authenticator	TSManager	2014-02-04 12:43:45	1672 (0x0688)

• Edited by Terje With Lunndal Wednesday, February 05, 2014 9:15 AM Specified deployment to VM, not physical host.

seemingly random file.

So it's a different file each time.

80072ee2 = The operation timed out.

It could be a transient network error. Have you tried re-creating the scripts and the Toolkit package?

We're also experiencing the same problem in two of our environments. Seemingly random file every time, but always in the Toolkit-package. We're using SCCM 2012R2 with the KB2905002 and KB2907591 hotfixes, and MDT2013.

What we've tried so far:

- Recreated the toolkit package

- Recreated the entire task sequence and all accompanying packages (even bootimages and client)

Last night I also reinstalled the entire server, scrapped the old database, recreated everything from scratch.

Still fails.

What I've seen, is that when it fails, the log halts for 21 seconds.

<![LOG[Downloaded file from http://NSH-C1-SCCM-02.<domain>.LOCAL:80/SMS_DP_SMSPKG$/NSH00012/sccm?/Scripts/DeployWiz_Applications.xml to C:\_SMSTaskSequence\Packages\NSH00012\Scripts/DeployWiz_Applications.xml ]LOG]!><time="23:40:16.233+480" date="02-05-2014" component="InstallSoftware" context="" type="1" thread="2128" file="downloadcontent.cpp:1574">
<![LOG[WinHttpSendRequest (hRequest, pszAdditionalHeader != NULL ? pszAdditionalHeader : WINHTTP_NO_ADDITIONAL_HEADERS, (DWORD)-1, NULL, 0, 0, NULL), HRESULT=80072ee2 (e:\nts_sccm_release\sms\framework\tscore\downloadcontent.cpp,1193)]LOG]!><time="23:40:37.457+480" date="02-05-2014" component="InstallSoftware" context="" type="0" thread="2128" file="downloadcontent.cpp:1193">
<![LOG[WinHttpSendRequest failed.]LOG]!><time="23:40:37.457+480" date="02-05-2014" component="InstallSoftware" context="" type="3" thread="2128" file="downloadcontent.cpp:1193">

- It always fail on the toolkit-package

- The tookit-package is downloaded afterwards, completely ok, in the "Gather Logs and StateStore on Failure".

- It is no difference if I deploy to physical or virtual hardware. 

Just to make it even more exciting.. We're experiencing the same on both 2012R2 and 2008R2 servers (two different installations)

Pretty obscure... 

But have you, by any chance changed the "Set Variable for Drive Letter"? Is it set to "True"? 

Set it to "False", and your sequence should go through (and you'll get windows installed on D: or E: or some other letter)

This has been reported to Microsoft Premier Support with proper logging.

Hi Terje,

Have you had any luck with fixing your problem yet?  We're experiencing a similar problem, also running SCCM 2012 R2.  It's been driving me crazy for a week as this only appears to be affecting deployments from our central site server which has a co-located distribution point.  Our two other sites which have DPs are unaffected.

What I've observed is that the error occurs at a particular point in the TS so will effect a particular package (random file in that package) or the package before or after.  I've been holding off logging a support case with MS due to the "randomness" of this problem and the possibility that it might be caused by something in our infrastructure outside of SCCM.

Anyway, if you've made any progress it would be great to hear about it.

Thanks Christian,

You just saved me a lot of troubleshooting. You are spot on with the "Set Variable for Drive Letter". I changed it to "True" to work around an issue in a VB Script. I've now changed it back to "False" but have not gotten consistent results. I'll try som more this weekend and post my result back here.

Please let me know if you make any progress and I'll keep you posted as well.

Thanks again,

Terje

Just a quick update on my part. I have not had a chance to perform any more testing due to other issues with my lab environment. Fingers crossed for a few spare hours during this week. I'll post back as soon as I have any results.

We got a reply from Microsoft

- The issue as been verified in their lab, and they are working on a proper solution.

- The workaround suggested by them is as follows:

Create two Task Sequence Variables at the very top of the TS, right below "Execute Task Sequence" 

SMSTSDownloadRetryCount = 5

SMSTSDownloadRetryDelay = 15

I've done this myself, and the TS now completes.

• Marked as answer by Terje With Lunndal Sunday, February 16, 2014 2:47 PM

Yes those variables were added in R2, along with another one SMSTSMPListRequestTimeout. This works around a similar issue where systems fail to download policy during an install application action immediately after a system restart. It's more common with systems that have SSD's. Similarly to the other two relating to content download it's not a fix to the problem, just a workaround.

You may want to set SMSTSMPListRequestTimeout to 300 (5 mins). The 5 min wait and retry will only occur if the install application action fails to download policy, so no impact if the action works as expected.

Mark.

• Edited by Mark_Thomas Wednesday, February 12, 2014 7:59 PM

This is great news. I just tried the workaround with the new TS-variables and they did the trick.

Thanks for all your help and suggestions, guys! It's much appreciated.

Thank you! I was searching and troubleshooting nearly two weeks and this finally solved the problem!

Thank you so much!

We got a reply from Microsoft

- The issue as been verified in their lab, and they are working on a proper solution.

- The workaround suggested by them is as follows:

Create two Task Sequence Variables at the very top of the TS, right below "Execute Task Sequence" 

SMSTSDownloadRetryCount = 5

SMSTSDownloadRetryDelay = 15

I've done this myself, and the TS now completes.

Just wanted to confirm that this worked for me at a recent client, another MVP also had the issue and it worked for him as well.

Setting the variables, also improved the OS image download speed as well.

Microsoft is aware of the bug and it's filed, hopefully we'll have a hotfix to address soon.

We got this similar error 80072ee2 when trying to run User State Restore during OSD. Setting these 2 variables manually as described resolved our issue. 

Hi...just discovered the thread today...

Anyway I thought I'd add a few details that might help people:

1. We deploy almost entirely on Lenovo Machines...setting there BIOS to "Legacy" instead of "Default" seemed to help with the issue.

2. 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"

Has anyone else actually raised the issue with Microsoft Premier support.  The more incident reports they get, and the more information that can be gathered in support incidents the better.  This helps get the issue looked into and resolved faster.  Remember since this is a bug you shouldn't be charged for the incident.

Thank you very much. It solved our problem as well.

I have placed a new incident at Premier Support with this Bug. Hope it makes a little pleasure on the issue. ;-)

Hi Stefan,

Any update from MS.

I have 2 DPs and this issue only happens on 1 remote DP starting 2 months ago.

I have added the TS variable to increase the delay and retry but it only improves a bit. The OSD fails only during the package deployment such as Sophos. Not randomly as before. The Drive Letter variable was set to False to make sure the systems drive is "C".

Anybody else has different solution?

Thank you for sharing. - Hadi

Hi Hadi

There are no news from MS and I do not expect much, but it is still open. I have written a business impact that may help to get more pressure on it. There are no more workarounds.

I don't know but some executables are "blocked". This you can check in the properties of the file. Then there is a "unblock" button next to the advanced button.

This might be the case. Then unblock the file in your source dir and redistribute the package to the DP.

Hi,

I tried setting "Do not assign a drive letter" to the BDEDrive partition in the format and partition step. And then set the OSDPreserveDriveLetter to False. I also selected apply operating system to specific drive letter c:\ and now i still have bitlocker working and the image apply to c:\.

So this workaround seems to work for me. I haven't had the possibility to test a volume of computers with this workaround but at least the OSDPreserveDriveLetter is set to false now with image applying to c:\

/ Dan