OSD fails to half of computers error 0x80072ee2 and others

[j1mmyd3an]

OK so I just wanted to post an update. I changed one setting on all of my distribution points; I unchecked "Allow fallback source location for content". This setting has been enabled and working fine for 3 weeks so I don't know what happened, but now my imaging works again. I have successfully deployed 5 workstations since unchecking that option. It may be a coincidence but since making that change everything is back to working.

 

Anyway, I'm keeping that setting disabled and I'll post back with an update if anything changes.

[j1mmyd3an]

Well it looks like I spoke too soon. Imaging is back to not working again. Same timeout error message as before.

 

It was nice while it lasted...

[rozzer85]

I have still not come up with a solution and I am also running on Windows Server 2012.

 

Thanks,

 

Ross

[Sighlent]

BUMP!

 

I am having the same issue as listed above. SCCM 2012, SVR2012.

 

All machines work fine except for one model (which was working last week). They are all the same brand laptop but the model with the issue does happen to use UEFI(I don't think that should matter but...)

 

Now, for some reason, this one model will get to anywhere from 5% to 85% downloaded and then fail.

 

Any suggestions?

 

Thanks.

[Sighlent]

This may help some people. In my case, it was an issue with a USB to Ethernet dongle. We purchased Lenovo Carbon X1's for our employees and it is a very thin laptop with no built in ethernet port. The supplied Lenovo USB 2.0 to 10/100 Ethernet adapter would download the image from the SCCM server at about 1G every 90-100 seconds. This was apparently too slow. Even though we brought up a command prompt and did a constant ping and it never dropped a packet, at some random percentage it would just stop downloading and say it lost connection. Even though it never actually did. We tried the new drivers another website recommends for the dongle straight from the dongle manufacturer but to no avail.

We then bought a USB 3.0 to Gigabit Ethernet adapter(not available from Lenovo), loaded the files into the base image, had SCCM build a bootable USB media.

Plug in the USB, plug in the (non working yet) USB 3.0 adapter, boot from the USB, let it load the drivers and you could see the link light come on and then WinPE took over from there and ran successfully every time.

It now downloads the image at 1G every 17-18 seconds.

[TheMoose]

This helped me!! It's a shame we all have to waste so much time trying to figure this part out. I went through the same exact issue on the Asus UX31's last year and wouldn't you know it, the Lenovo X1 Carbon has the same ASIX adapter hence the same problem.

 

In short, if you have a fully functional SCCM OSD image that is working across multiple models and manufacturers across multiple sites and you can't get an Asus UX31 or Lenovo X1 to image, ditch the USB dongle for both of them, the Belkin F4U061 worked fine for me.

 

After several weeks of headaches and having the image stop at random percentages at the same step everytime "apply operating system image" and only on this specific model of computer, switching the adapter as recommended above worked right away. (Would seem to be driver related but all tests validated successfully so it's hard to pin down the exact issue with those adapters (pinging, package access, etc). The Lenovo doesn't support PXE on the new adapter so i had to go bootable usb as recommended above. (worked great, thanks man)

 

This did not help: http://scug.be/sccm/2013/05/27/lenovo-x1-not-pxe-booting-in-configmgr-2012-sp1/

This is what I was seeing in the SMSTS.log: http://www.windows-noob.com/forums/index.php?/topic/7442-sccm-2012-windows-7-os-deployment-failure-0x80072efe/

On the failed machine itself it always showed an 80070002 at the apply os image step.

 

Thanks guys. - Moose

[derrynm]

I was really hoping someone had found a solution to this. My problem is similar.

 

I have a task sequence that fails while downloading the WIM. It starts downloading, gets to a certain percentage then starts over, it does this a couple times before failing with error 80070002.

ReadDataAndWriteToFile() failed with 0x80072ee2 when downloading 16% of file C:\_SMSTaskSequence\Packages\PRK00025\ENx64W7.wim

ReadDataAndWriteToFile() failed with 0x80072ee2 when downloading 39% of file C:\_SMSTaskSequence\Packages\PRK00025\ENx64W7.wim

 

Here's the really strange part, If I F8 and ping the server, it replies and the download continues. The ping is losing packets which I suspect is why the download is failing. I plug into the same port with a working laptop and I don't lose packets. I tried updating the drivers in the Boot WIM to the most current version, older versions, same result. I know it's not Network Access Account since the download starts (and finishes as long as I'm pinging). Any ideas?

 

I've tried newer drivers, older drivers, boundary's look good, This is killing me!

[derrynm]

I was really hoping someone had found a solution to this. My problem is similar.

 

I have a task sequence that fails while downloading the WIM. It starts downloading, gets to a certain percentage then starts over, it does this a couple times before failing with error 80070002.

ReadDataAndWriteToFile() failed with 0x80072ee2 when downloading 16% of file C:\_SMSTaskSequence\Packages\PRK00025\ENx64W7.wim

ReadDataAndWriteToFile() failed with 0x80072ee2 when downloading 39% of file C:\_SMSTaskSequence\Packages\PRK00025\ENx64W7.wim

 

Here's the really strange part, If I F8 and ping the server, it replies and the download continues. The ping is losing packets which I suspect is why the download is failing. I plug into the same port with a working laptop and I don't lose packets. I tried updating the drivers in the Boot WIM to the most current version, older versions, same result. I know it's not Network Access Account since the download starts (and finishes as long as I'm pinging). Any ideas?

 

I've tried newer drivers, older drivers, boundary's look good, This is killing me!

[Sneakthief]

I resolved this by redistributing the Operating System wim.