We have around 20 computers all deploying at the same time and a number of them have failed with the following snippet visible in the smsts.log that was copied back up to the server as part of our task sequence.

****** START OF LOG SNIPPET ******

DAV response string is: 
 <?xml version="1.0" encoding="utf-8" ?><D:multistatus xmlns:D="DAV:"><D:response><D:href>http://one.of.our.dps/NOCERT_SMS_DP_SMSPKG$/sccm?/DIT00407/</D:href><D:propstat><D:status>HTTP/1.1 200 OK</D:status><D:prop><D:getcontenttype/><D:supportedlock/><D:getetag/><D:creationdate/><D:iscollection>1</D:iscollection><D:resourcetype><D:collection/></D:resourcetype><D:ishidden>0</D:ishidden><D:displayname>http://one.of.our.dps/NOCERT_SMS_DP_SMSPKG$/sccm?/DIT00407/</D:displayname><D:getlastmodified></D:getlastmodified><D:getcontentlanguage/><D:getcontentlength>0</D:getcontentlength></D:prop></D:propstat></D:response><D:response><D:href>http://one.of.our.dps/NOCERT_SMS_DP_SMSPKG$/DIT00407/sccm?/Win7x64sp1_ASS_9.3.0.wim</D:href><D:propstat><D:status>HTTP/1.1 200 OK</D:status><D:prop><D:getcontenttype/><D:lockdiscovery/><D:supportedlock/><D:getetag/><D:getcontentlanguage/><D:iscollection>0</D:iscollection><D:creationdate/><D:resourcetype/><D:ishidden>0</D:ishidden><D:displayname>http://one.of.our.dps/NOCERT_SMS_DP_SMSPKG$/DIT00407/sccm?/Win7x64sp1_ASS_9.3.0.wim</D:displayname><D:getlastmodified>Wed, 18 Mar 2015 11:26:23 GMT</D:getlastmodified><D:getcontentlength>7528167965</D:getcontentlength></D:prop></D:propstat></D:response></D:multistatus> ApplyOperatingSystem 25/03/2015 09:40:40 1604 (0x0644)
List of files to be downloaded ApplyOperatingSystem 25/03/2015 09:40:40 1604 (0x0644)
  File: http://one.of.our.dps:443/NOCERT_SMS_DP_SMSPKG$/DIT00407/sccm?/Win7x64sp1_ASS_9.3.0.wim ApplyOperatingSystem 25/03/2015 09:40:40 1604 (0x0644)
GetDirectoryListing() successfully completed ApplyOperatingSystem 25/03/2015 09:40:40 1604 (0x0644)
401 - Unsuccessful with anonymous access. Retrying with context credentials. ApplyOperatingSystem 25/03/2015 09:40:40 1604 (0x0644)
401 - Unsuccessful with context credentials. Retrying with supplied credentials. ApplyOperatingSystem 25/03/2015 09:40:40 1604 (0x0644)
SetFilePointer (hDestFile, 0, NULL, FILE_END) != INVALID_SET_FILE_POINTER, HRESULT=80070057 (e:\qfe\nts\sms\framework\tscore\downloadcontent.cpp,1408) ApplyOperatingSystem 25/03/2015 09:40:40 1604 (0x0644)
SetFilePointerEx() failed. ApplyOperatingSystem 25/03/2015 09:40:40 1604 (0x0644)
DownloadFileWithRanges() failed. 80070057. ApplyOperatingSystem 25/03/2015 09:40:40 1604 (0x0644)
DownloadFileWithRanges (hSession, hConnect, sRequest, hFile, pszDestination, ullFileSize, ulPackageSize, ulDownLoaded, LastGoodCredentialsType, bUseSSL), HRESULT=80070057 (e:\qfe\nts\sms\framework\tscore\downloadcontent.cpp,1514) ApplyOperatingSystem 25/03/2015 09:40:40 1604 (0x0644)
DownloadFile() failed for http://one.of.our.dps:443/NOCERT_SMS_DP_SMSPKG$/DIT00407/sccm?/Win7x64sp1_ASS_9.3.0.wim, D:\_SMSTaskSequence\Packages\DIT00407\Win7x64sp1_ASS_9.3.0.wim. 80070057. ApplyOperatingSystem 25/03/2015 09:40:40 1604 (0x0644)
DownloadFile (hSession, hConnect, sSourceFile.c_str(), sDestinationFile.c_str(), ulPackageSize, ulDownLoaded, LastGoodCredentialsType, bUseSSL), HRESULT=80070057 (e:\qfe\nts\sms\framework\tscore\downloadcontent.cpp,1590) ApplyOperatingSystem 25/03/2015 09:40:40 1604 (0x0644)
Error downloading file from http://one.of.our.dps:443/NOCERT_SMS_DP_SMSPKG$/DIT00407/sccm?/Win7x64sp1_ASS_9.3.0.wim to D:\_SMSTaskSequence\Packages\DIT00407\Win7x64sp1_ASS_9.3.0.wim ApplyOperatingSystem 25/03/2015 09:40:40 1604 (0x0644)
DownloadFiles() failed. 80070057. ApplyOperatingSystem 25/03/2015 09:40:40 1604 (0x0644)
DownloadFiles (setDirs, setFiles, sDestination.c_str(), bUseSSL), HRESULT=80070057 (e:\qfe\nts\sms\framework\tscore\resolvesource.cpp,2529) ApplyOperatingSystem 25/03/2015 09:40:40 1604 (0x0644)
Download() failed. 80070057. ApplyOperatingSystem 25/03/2015 09:40:40 1604 (0x0644)
DownloadContentAndVerifyHash() failed. 80070002. ApplyOperatingSystem 25/03/2015 09:40:40 1604 (0x0644)
DownloadContentAndVerifyHash ( pszPackageID, L"SMSPackage", saHttpContentSources, saSMBContentSources, saMulticastContentSources, sDestination, dwFlags, L"", 0, dwPackageFlags, mapNetworkAccess ), HRESULT=80070002 (e:\qfe\nts\sms\framework\tscore\resolvesource.cpp,3052) ApplyOperatingSystem 25/03/2015 09:40:41 1604 (0x0644)
DownloadContentLocally (pszSource, sSourceDirectory, dwFlags, hUserToken, mapNetworkAccess), HRESULT=80070002 (e:\qfe\nts\sms\framework\tscore\resolvesource.cpp,3273) ApplyOperatingSystem 25/03/2015 09:40:41 1604 (0x0644)
TS::Utility::ResolveSource( this->packageID, this->packagePath, TS::Utility::ResolveSourceFlags::PersistContents | (this->forceRunFromNet ? TS::Utility::ResolveSourceFlags::ForceRunFromNet : 0) ), HRESULT=80070002 (e:\nts_sccm_release\sms\client\osdeployment\applyos\installimage.cpp,1767) ApplyOperatingSystem 25/03/2015 09:40:41 1604 (0x0644)
resolvePkgSource(), HRESULT=80070002 (e:\nts_sccm_release\sms\client\osdeployment\applyos\installimage.cpp,1810) ApplyOperatingSystem 25/03/2015 09:40:41 1604 (0x0644)
Apply(), HRESULT=80070002 (e:\nts_sccm_release\sms\client\osdeployment\applyos\installimage.cpp,2019) ApplyOperatingSystem 25/03/2015 09:40:41 1604 (0x0644)
Installation of image 1 in package DIT00407 failed to complete.. 
The system cannot find the file specified. (Error: 80070002; Source: Windows) ApplyOperatingSystem 25/03/2015 09:40:41 1604 (0x0644)
installer.install(), HRESULT=80070002 (e:\nts_sccm_release\sms\client\osdeployment\applyos\installimage.cpp,2094) ApplyOperatingSystem 25/03/2015 09:40:41 1604 (0x0644)
ReleaseSource() for D:\_SMSTaskSequence\Packages\DIT00407. ApplyOperatingSystem 25/03/2015 09:40:41 1604 (0x0644)
The user tries to release a source directory D:\_SMSTaskSequence\Packages\DIT00407 that is either already released or we have not connected to it. ApplyOperatingSystem 25/03/2015 09:40:41 1604 (0x0644)
InstallImage( g_InstallPackageID, g_ImageIndex, targetVolume, ImageType_OS, g_ConfigPackageID, g_ConfigFileName, bOEMMedia, g_RunFromNet ), HRESULT=80070002 (e:\nts_sccm_release\sms\client\osdeployment\applyos\applyos.cpp,509) ApplyOperatingSystem 25/03/2015 09:40:41 1604 (0x0644)
Process completed with exit code 2147942402 TSManager 25/03/2015 09:40:41 1060 (0x0424)
!--------------------------------------------------------------------------------------------! TSManager 25/03/2015 09:40:41 1060 (0x0424)
Failed to run the action: Windows 7 x64 (ASS 9.3.0). 
The system cannot find the file specified. (Error: 80070002; Source: Windows) TSManager 25/03/2015 09:40:41 1060 (0x0424)
MP server https://ict-deploy01.windows.tees.ac.uk. Ports 80,443. CRL=false. TSManager 25/03/2015 09:40:41 1060 (0x0424)
Setting authenticator TSManager 25/03/2015 09:40:41 1060 (0x0424)
Set authenticator in transport TSManager 25/03/2015 09:40:41 1060 (0x0424)
Sending StatusMessage TSManager 25/03/2015 09:40:41 1060 (0x0424)
Setting message signatures. TSManager 25/03/2015 09:40:41 1060 (0x0424)
Setting the authenticator. TSManager 25/03/2015 09:40:41 1060 (0x0424)
CLibSMSMessageWinHttpTransport::Send: URL: ict-deploy01.windows.tees.ac.uk:443  CCM_POST /ccm_system_AltAuth/request TSManager 25/03/2015 09:40:41 1060 (0x0424)
In SSL, but with no client cert TSManager 25/03/2015 09:40:41 1060 (0x0424)
Request was successful. TSManager 25/03/2015 09:40:41 1060 (0x0424)
Set a global environment variable _SMSTSLastActionRetCode=-2147024894 TSManager 25/03/2015 09:40:41 1060 (0x0424)
Set a global environment variable _SMSTSLastActionSucceeded=false TSManager 25/03/2015 09:40:41 1060 (0x0424)

****** END OF LOG SNIPPET ******

I have made bold and underlined the sections which may be useful.

Does this have something to do with our certificates/SSL setup? Why is it working on some clients and failing like this on a small number? As I said we are running this on around 20 machines at once. Four have failed with an almost identical log to this.

Any help or suggestions would be greatly appreciated!

IIS logs show an entry like this. (replaced identifying portion of IP with x's)

152.xxx.211.62 GET /NOCERT_SMS_DP_SMSPKG$/DIT00407/sccm /Win7x64sp1_ASS_9.3.0.wim 443 - 152.xxx.219.149 SMS+CCM+5.0+TS - 401 2 5 1541 15

Again i have underlined the part i feel is pertinent. it looks like a 401.2 error.

This is swiftly followed by

152.xxx.211.62 GET /NOCERT_SMS_DP_SMSPKG$/DIT00407/sccm /Win7x64sp1_ASS_9.3.0.wim 443 - 152.xxx.219.149 SMS+CCM+5.0+TS - 401 1 2148074252 1541 0

Which looks like a 401.1 error. These repeat several times. This is making me think something isn't right with our certs or HTTP/HTTPS setup. What else confuses me is it looks like its using 443 port but the prefix in the SMSTS.LOG from my first post appears to use the HTTP:// prefix why not HTTPS://

What is also strange is it seems to be working on the majority of clients this only happens on some which we initially thought could be a network limitation due to us trying to run too many OSD TS's from the same DP at one time.

We are clutching at straws here so any advice or help would be greatly appreciated.

This is a product bug. This will only happen if download is being retried and there is already more than 4 GB of data downloaded on the first try.

The sequence goes like this:

1. First attempt to download failed. It has already downloaded 7 GB. There is a remaining 3 GB to be downloaded.

2. The retry will now attempt to download the remaining 3 GB. This will fail.

In contrast, this sequence works:

1. First attempt to download failed. It has already downloaded 2 GB. There is a remaining 8 GB to be downloaded.

2. The retry will now attempt to download the remaining 8 GB. This will succeed.

I suggest that you contact support and file a bug.

• Edited by Kerwin MedinaMicrosoft employee 12 hours 49 minutes ago
• Proposed as answer by Jason SandysMVP 10 hours 31 minutes ago

This is a product bug. This will only happen if download is being retried and there is already more than 4 GB of data downloaded on the first try.

The sequence goes like this:

1. First attempt to download failed. It has already downloaded 7 GB. There is a remaining 3 GB to be downloaded.

2. The retry will now attempt to download the remaining 3 GB. This will fail.

In contrast, this sequence works:

1. First attempt to download failed. It has already downloaded 2 GB. There is a remaining 8 GB to be downloaded.

2. The retry will now attempt to download the remaining 8 GB. This will succeed.

I suggest that you contact support and file a bug.

• Edited by Kerwin MedinaMicrosoft employee Wednesday, March 25, 2015 6:53 PM
• Proposed as answer by Jason SandysMVP Wednesday, March 25, 2015 9:10 PM

This is a product bug. This will only happen if download is being retried and there is already more than 4 GB of data downloaded on the first try.

The sequence goes like this:

1. First attempt to download failed. It has already downloaded 7 GB. There is a remaining 3 GB to be downloaded.

2. The retry will now attempt to download the remaining 3 GB. This will fail.

In contrast, this sequence works:

1. First attempt to download failed. It has already downloaded 2 GB. There is a remaining 8 GB to be downloaded.

2. The retry will now attempt to download the remaining 8 GB. This will succeed.

I suggest that you contact support and file a bug.

• Edited by Kerwin MedinaMicrosoft employee Wednesday, March 25, 2015 6:53 PM
• Proposed as answer by Jason SandysMVP Wednesday, March 25, 2015 9:10 PM
• Marked as answer by d4rkcell 7 minutes ago

Thanks Kerwin. So our WIM file is around 6 or 7 GB. What your saying is after it has downloaded 4 GB it will bomb if it needs to retry? Would a workaround be to try and limit WIM file size to be around the 4 GB mark?

I am also wondering if there may be some way the WIM file can be split into say x4 2 GB files, downloaded via PE, joined and then applied. May also be possible to workaround by pre-staging the WIM file?

You should have no problem with 6 or 7 GB files as long as the download completes in one try.

The problem is if the download fails in the first attempt and a retry is needed. Even at that, the retry will only fail if the first attempt managed to download more than 4 GB.

OK Kerwin, thanks. I'm just wondering if there is any way to find out why the download might have failed on the first try? Should that information be further up in the smsts.log or will it be buried in the IIS logs somewhere? Would really like to minimize the amount of times this is happening as it seems to be random and our users get pretty annoyed pretty easily when the computer lab has a handful of non-functioning workstations. It disrupts classes.

We have had consultants on campus to investigate this issue but what they have suggested makes no sense, they suggest adding a secondary site - that's another post! I don't want to do this so would love to get the bottom of what's causing the download to fail and subsequently for the retry to fail. Could it be something at the network level e.g. switch configuration causing loss of packets? Do you think multicasting the WIM file would work better?

We have been monitoring the primary site server disk and CPU loads as well as the Distribution Point disk and CPU and there is nothing here to indicate a bottleneck on the servers. This leaves me wondering if the network could be the culprit.

Thanks again for your comments thus far.

One option you can try is to enable download via SMB.

You do this by enabling the package/content option for "Copy the content in this package to a package share on distribution points:" This is on the "Data Access" tab of the package property page.

Once you enable this, wait for the distribution points to create the SMB share for the package. Then you can run your TS.

What will happen is, when the HTTP download fails, the SMB option will be tried. The SMB download does not have a problem with large retries.

One option you can try is to enable download via SMB.

You do this by enabling the package/content option for "Copy the content in this package to a package share on distribution points:" This is on the "Data Access" tab of the package property page.

Once you enable this, wait for the distribution points to create the SMB share for the package. Then you can run your TS.

What will happen is, when the HTTP download fails, the SMB option will be tried. The SMB download does not have a problem with large retries.

• Marked as answer by d4rkcell 7 minutes ago

Kerwin that's great do you know if this "fallback" happens automatically or if I need to enable "Access content directly from distribution point" in the options tab of the apply operating system step in the task sequence?

If it happens automatically without having to do this then I think that is the way forward for us. We don't want to force it to use SMB every time only when HTTP fails.

Thanks again!

The fallback to SMB will just happen, assuming that you enabled SMB download for the package.