PXE Boot - Loading files takes hours!!!

Question

_{Friday, November 13, 2015 8:13 PM}

Alright I have seen some posts in regards to this issue but the KBs do not apply to my setup.

Setup:

OS - Windows Server 2012 R2

CPU - 8

Ram - 30GB

NIC: 10GB Connection (1GB infrastructure to endpoints)

Version: SCCM 2012 R2 SP1

The DHCP server is hosted separately and the WDS resides on the Primary Standalone server of SCCM. I am trying to PXE boot some laptops and OMG it takes eternity to get to my SCCM Splash screen.

I have changed the registry setting set to:

I even changed it to the next setting higher in blocks of 4096, restart the WDS Service, no change in download speed.

Checked the network connection on my SCCM server, WDSServer is around 30-34k speed....?????

I verified the Address matched the laptop I was trying to PXE boot from.

KB2910552 will not install as I am running 2012 R2 SP1 and I assumed that SP1 would address this issue but it has not. Does anyone have suggestions or knowledge on how to fix this issue? I am literally going crazy dealing with 1 full day to image 1 computer.

All replies (9)

_{Monday, November 23, 2015 8:33 PM ✅Answered}

I am stumped, it started working just fine when running a test....Not sure if the network was saturated when performing a PXE boot or if it took a moment to realize that RamDiskTFTPBlockSize was added or not, either way we will take the win!

Thanks everyone that responded!

_{Friday, November 13, 2015 9:05 PM}

Ultimately, this is outside of ConfigMgr itself. Some things I've seen cause poor TFTP speeds include "funky" NIC BIOS, VMWare VMXNet3 NICs, and other network level configuration. There are a lot of possibilities here and you really should get one of your network guys involved to help track down exactly what's causing the slowness. Upgrading the BIOS of the NIC on the system being PXE booted is a possibility if this is only happening on one system -- which begs the question: Have you tried on multiple different systems or just one? Also, the VMXNet3 NIC implementation in VMWare is ... well ... the source of many, many connectivity issues.

Jason | http://blog.configmgrftw.com | @jasonsandys

_{Friday, November 13, 2015 10:53 PM}

Jason,

Thanks for the reply. I am running the SCCM server on Hyper-V Failover Cluster with NIC teaming. It is only 1 SCCM server that hosts the DP, MP, and WDS roles. I confirmed it is not a network issue as the ports are showing full duplex with no errors on the Cisco Switch.

I am thinking it is a NIC Driver issue on the Hyper-V NICs considering they are over 2 years old. I will have to schedule some time to update the drivers to confirm that is the issue.

_{Saturday, November 14, 2015 12:17 AM | 2 votes}

In the process of downloading the boot WIM, there is no SCCM component involved. The client program that is doing the download is bootmgr.exe which is from the ADK (inside the default boot WIM). The one serving the content is WDS. SCCM will only get involved once WinPE has started (WinPE will run the TS shell).

I suggest that you get WDS support and ADK support involved. You can also file a request with the ADK team for bootmgr.exe to add HTTP download of WIMs.

I also suggest that you capture the traffic with network trace. The download of boot WIMs are done using TFTP. It should be relatively easy to trouble shoot TFTP because it is a locked-step protocol - you will see one acknowledgement packet for every data packet - in alternating pattern, and the packets are all UDP.

My guess is that packets are getting lost in you network. Packet loss is devastating to a locked-step protocol like TFTP because the server will not send the next block unless it gets an acknowledgement for the current block.

Note also that using a bigger block size, like 8K, will not necessarily speed-up TFTP. The Ethernet frame only has a payload of less than 1.5K. Sending an 8K block requires multiple Ethernet frames. If one frame is lost, the entire block is bad. Using bigger blocks is good if your network is error-free. But in the case of an error-prone network, block sizes that are closest to the maximum Ethernet payload size is better.

_{Monday, November 16, 2015 5:11 PM}

Kerwin,

Could you dumb down your response for me please? We don't have a WDS/ADK team. I am the only one in charged of this side of the fence per say. Not sure how you add HTTP download to bootmgr.exe, etc. Searching the web has not helped me thus far, perhaps in the type of words I am using in my search.

Thanks.

_{Monday, November 16, 2015 5:34 PM}

Kerwin was referring to opening a case with Microsoft.  Ultimately, as has been stated, you need to involve someone who can validate your network is functioning as expected and that network performance is sufficient for the tasks at hand.  Do you have a network team that can assist to make sure there is no packet loss or anything else impeding the download of your boot image?

Jeff

_{Monday, November 16, 2015 6:30 PM | 1 vote}

I've personally never had too much success in changing the TFTPBlockSize.  At first it always seems like its made difference but then on particular models of machines it will be grudgingly slow.

Suggest moving forwards you go back to defaults.

_{Monday, November 16, 2015 6:30 PM}

Jeff,

Thank you for a quick response. I do and I will be setting up sometime to perform a network trace on the PXE process to determine the bottleneck. Hope to figure this out!

_{Tuesday, November 17, 2015 7:17 AM}

Edit the dll (well outside the scope of SCCM support)

http://www.bctechnet.com/vmware-pxe-limitations/

(it does NOT only apply to Vmware)

Edit the bcd to correspond

https://technet.microsoft.com/en-us/library/cc731245%28v=ws.10%29.aspx

Read it twice/three times if you need to understand. Play with values to see what suits you best

Makes my 450 Mb wim load on Dell Optiplex 3020 in under 10 seconds

Seb