Slow PXE Booting

[Harvey]

Hello,

 

I got PXE boot working but it's taking over 3-5 minutes to load the boot wim file that's 150MB.

 

My PXE server is on the same gigabit switch as the desktops and is running Windows 2008. At the time it takes to deploy the boot wim file I could have already been half way into deploying the 3.5GB O/S image if I booted up using a CD. It seems to vary on different computers and funny that hte older GX620 are faster in loading the boot WIM faster than the 760 and 745.

 

Since I never had experience with it before it, what is the normal time it takes to PXE boot a wim file?

 

Also if I load more than one boot wim like one for production and one as a test for new drivers, does it prompt an option to load or I should only have one on there?

 

Thanks,

 

Harvey

[anyweb]

sounds about right to be honest, however have you tried varying your nic speed from gigabit to different duplex settings ? is there a switch between you and the clients ?

[Harvey]

sounds about right to be honest, however have you tried varying your nic speed from gigabit to different duplex settings ? is there a switch between you and the clients ?

 

I think the problem is with Windows 2008. I got WDS working on a windows 2003 box and it loads it up faster in a matter of 5-10 seconds. I wonder if it's the network profile that's available in WDS in 2008 that 2003 doesn't have. I set it to gigabit in 2008 because it and desktop are all on the same gigabit switch with gigabit ethernet but didn't think that'd be the issue.

 

I'll change to 100MBs and see if that makes a difference. It's bad enough that imaging is about 1hr 15-25 minutes, don't need another 5 minutes to add to it.

[anyweb]

well take a look at the webcasts here, specifically the PXE boot parts, you'll see that they are quite slow, but then again they are running on virtual machines (hyperv) and on Windows Server 2008,

where I'm working currently is using Windows Server 2003 and the PXE process is slow, I am assuming that is down to slow network/slow backend hardware (virtual servers) and possibly QOS throttling on the network

[YiannosG]

This is something that works on SCCM. dont know if you can use it for WDS as well

 

Modify your SCCM's registry as follow

 

Location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\PXE

Name: RamDiskTFTPBlockSize

TYPE: REG_DWORD

Value:4000 (Hex)

 

It will speed up the TFTP transfer of the Ram drive boot image when booting

 

Follow this quide for WDS settings

 

http://www.idi.ntnu.no/~jang/dokument/WDSupdate/Individual%20Chapters/_Chapter%207%20-%20Working%20with%20Images.htm

[Mikey C]

I understand this is an old post, but still relevant to PXE in SCCM 2012 (in my case with WDS on Server 2012 R2).

 

These two posts were instrumental in improving the situation:

 

http://netecm.netree.ch/blog/Lists/Posts/Post.aspx?ID=57#.UwYmb_l_tnE

 

http://wibier.me/pxe-boost-sccm-2012/

 

http://blog.uvm.edu/jgm/2010/11/04/tuning-microsoft-pxe-tftp/

 

http://windowsdeployments.net/how-to-speed-up-pxe-boot-in-wds-and-sccm/

[cgbolton1]

Ok so I am not trolling this thread after getting my Configuration Manager current branch 1702 with the May updates installed to actually PXE Boot (I talked about that in another thread) but now I am dealing with incredibly slow speed to boot up. I don't even know how well the thing will handle the TS because it takes so long to actually boot the WIM file for the image build. I am pulling the file from a server at another site but we have a very large pipe and I can easily transfer multi-gig files in a a very short time. The WIM file for WinPE5 can't be that large but it is dragging on for about an hour. I have messed with the TFTPWindowSize, the RAMDiskSize the MAXBlockSize (which is what allowed it to work and not timeout) but nothing seems to make a big difference. I am not sure if there is a log that I can look at or if I have to resort to packet tracing but I desperately want to get this issue resolved so I can move forward again. Any help would be greatly appreciated!

Thanks,

Chris